This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
As discussed in mail... > Are the -Xms32m and -XX:PermSize=32m getting scaled/tweaked as well? > I've seen them recommended at -Xms128m and -XX:PermSize=64m > for big memory systems. No, they aren't. Setting them to higher values only saves some GC cycles when small area is exhausted. It can be good to have -Xms scaled too. File such request to IssueZilla and assign to me (category 'ide'). We are not planning to scale PermSize at this moment. It can be adjusted to a different value if there is a good input indicating that it grows for most of users to certain common value(s). We thought about UI gestures collector as a way how to gather such data but it is not implemented yet. -Radim
I do not think this is a bug now. I can do this later.
Antonio wrote: > Hi, > > Setting a bigger -Xms makes startup faster. As far as I've seen NetBeans requires quite a bit of memory at startup (> 256Mb in 6 secs, as far as I've seen, depending on the modules you use), and setting a bigger initial heap size avoids the JVM growing it, so startup time is reduced. > Higher -Xms can save few full GCs during startup (that's why it is here BTW). Too high -Xms will cause larger heap than necessary. We would like to see heap growing more defensively over time including startup to be able to live with smaller footprint. It means we are not sure what is the best value or how to keep balance here yet. > If you set the size of the heap size, I'd suggest you setting the size of the young generation to something in between 20% to 40% of the heap size. This change is very important, in my opinion, because young generation size is usually too small, and NetBeans (and many other Java apps) require lots of temporary objects. A big enough young generation size avoids lots of minor collections. This makes good sense. Honestly we talked about this several times in the past but did not do our homework to verify the impact. Assuming that many people have IDE running for a long time the idea of heap sized more like in server application is interesting. > > Setting a higher -XX:PermSize is probably a good idea as well, because an IDE does lots of class handling, and all class information is stored there, as far as I can remember. > Yes, we know how to fill default size and kill the IDE so we have to increase this area. > Regarding the concurrent collector, I must say I don't really like it, although I admit it may be a good idea. Anyway if you decide to use it, I was wondering if -XX:+CMSIncrementalMode and -XX:+CMSIncrementalPacing could be also a good idea. These are part of the official Sun recomendations for CMS, available at paragraph 5.4.9.2 at > http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html > Can you file this to IssueZilla so it does not get lost? Assign to me or add my username to cc: ('rkubacki'). regards, Radim > Cheers, > Antonio >
Mostly performance related. Passing to Petr N.