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.
Summary: | Adjust default memory settings | ||
---|---|---|---|
Product: | platform | Reporter: | Tomas Pavek <tpavek> |
Component: | Launchers&CLI | Assignee: | Antonin Nebuzelsky <anebuzelsky> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | pjiricka, psuchomel, vv159170 |
Priority: | P2 | ||
Version: | 7.0 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 189905 | ||
Bug Blocks: |
Description
Tomas Pavek
2010-09-13 13:39:10 UTC
> There's increasing need in adjusting the default memory settings
> the launcher uses for the started JVM for the IDE.
Any feedback from real users what they are setting as Xmx and XX:MaxPermSize when they have the need for the increase?
Or any measurements by perf team what should be the reasonable increase?
For the record, the current algorithm is
-J-XX:MaxPermSize=200m (in netbeans.conf)
-J-Xmx(max(96,min(512,RAM/5)))m (computed by launcher)
this maps to
Xmx512m for RAM >= 2.5gb
Xmx409m for 2gb
Xmx204m for 1gb
BTW, recently I got a PermGen error while running Ant build - could there be a leak in the Ant area again? > could there be a leak in the Ant area see http://netbeans.org/bugzilla/show_bug.cgi?id=189905#c5 Question here is if leaks are the problem for permgen or if some users really go through the roof by using too much functionality in the IDE. But, why should that be the case now. 6.10 is rather a bit smaller than e.g. 6.0. For heap increase there may be more reasons, mainly users using NetBeans with larger projects... But it's not obvious what is the right increase then. I think current NetBeans is actually noticeably bigger than 6.0 when comparing the same feature areas (i.e. for the same area there is now more features, more classes). Another thing is the mentioned increase of use of 64bit systems which were not considered years ago. They need more memory (OTOH people usually have more physical memory on these systems). The idea was that we can improve the memory settings even if we have no exact proof about how many people need more memory legitimately and when it is just result of memory leaks. The default memory settings could scale better with the available memory, they don't really have to be bigger for all physical memory configs. For example: * Heap size - people really may need more when working on something extremely large, it is strange we give them only 512M even if they have corresponding HW like 8GB, 64bit. I think with 8GB we can afford to set more than 512m for max heap... * PermGen - there is no big overhead of bigger PermGen except taking address space - so why not to compute it based on available memory as well? With 8GB the address space is not a problem, OTOH with small memory (which can be the case when running in virtualized environment) this may deserve even less than current 200MB. Some adjustment in this direction could make the IDE work better for the users, regardless if there are memory/class leaks or not... > Heap - people really may need more when working on something extremely large Agreed that heap is related to the size of projects and I think we should do one change in the computation - increase the upper boundary from 512m to 768m and keep the rest of the formula untouched, i.e. -J-Xmx(max(96,min(768,RAM/5)))m (computed by launcher) which will map to Xmx768m for >=4gb (increased from 512m) Xmx614m for 3gb (increased from 512m) Xmx409m for 2gb (as before) Xmx204m for 1gb (as before) The 768m is still reasonable size of heap for GC to not be very time-consuming which could be the case for even larger heaps. Also keep in mind that on 32-bit systems the following rule applies - "(Managed Heap + native heap + (thread stack size * number of threads)) cannot exceed 2GB on 32bit x86" > PermGen - why not to compute it based on available memory as well? PermGen usage is not related to any size of user data, it is related to number of loaded classes and does not make too much sense to compute flexibly based on user's RAM I suggest we increase the max permgen size from 200m to 256m, i.e. -J-XX:MaxPermSize=256m (in netbeans.conf) It may help to eliminate increase of size of code in some areas since 6.0 (as you pointed out) and also for x64 users (the increase for them is not 2x but "only" a few tens of percents more (e.g. +20%) compared to 32-bits) ValidateClassLinkageTest in o.n.core tries to load all classes of modules in clusters currently available in nbbuild/netbeans and allows measuring permgen requirement in the case user would use all the functionality in his IDE instance. I got the following results on my 32-bit Ubuntu with JDK 6u22: cluster.config=basic 140m of permgen needed cluster.config=full 190m of permgen needed (full cluster config includes apisupport, cnd, dlight, enterprise, harness, ide, java, nb, php, platform, profiler, ruby, websvccommon) So, with some additional room reserved for 64-bit increase, I am going to set the max. permgen to the 256m. When not all of that is actually used, it eats the 256m chunk only from the virtual address space of the process. On the 32-bit the 256m for permgen plus 768m for heap (the upper boundary) plus thread stacks plus JVM overhead should still fit well in the 2gb virtual address space of the process. info about run on my 64 bit Linux system: cluster.config=basic ---------------------------- Product Version = NetBeans Platform Dev (Build 101022-0e82dc0d19ad) (#0e82dc0d19ad) Operating System = Linux version 2.6.32-24-generic running on amd64 Java; VM; Vendor = 1.6.0_20; Java HotSpot(TM) 64-Bit Server VM 16.3-b01; Sun Microsystems Inc. Runtime = Java(TM) SE Runtime Environment 1.6.0_20-b02 Non-heap memory usage: 207/348M ------------------------------------ Operating System = Linux version 2.6.32-24-generic running on i386 Java; VM; Vendor = 1.6.0_21; Java HotSpot(TM) Server VM 17.0-b16; Sun Microsystems Inc. Runtime = Java(TM) SE Runtime Environment 1.6.0_21-b06 Java Home = /opt/jdk/jdk1.6.0_21/jre Non-heap memory usage: 141/348M cluster.config=full failed with OOM:PermGen on 64 bit system in 64 bit mode btw, on 64 bit system in 32 bit java mode I have more memory consumption than in your scenario: Non-heap memory usage: 240/348M Please, tell me how to give more PermGen for the test to see memory consumption Ok. I got it: Operating System = Linux version 2.6.32-24-generic running on amd64 Java; VM; Vendor = 1.6.0_20; Java HotSpot(TM) 64-Bit Server VM 16.3-b01; Sun Microsystems Inc. Runtime = Java(TM) SE Runtime Environment 1.6.0_20-b02 Java Home = /usr/lib/jvm/java-6-sun-1.6.0.20/jre Non-heap memory usage: 352/648M To sum up, permgen if all classes are loaded: cluster.config=basic (Java / OS bits) 32/32 - 140m 64/64 - 207m cluster.config=full (Java / OS bits) 32/32 - 190m 32/64 - 240m 64/64 - 352m So, for the full config on 64-bit JVM all classes don't fit into the 256m permgen. Whatever probability there is for a user to really load all classes, I think it is a good idea to have the room for them reserved. I see two options - keeping MaxPermSize at 256m for 32-bit JVM and increasing to 384m for 64-bit JVM or - increasing MaxPermSize to 384m regardless of JVM Figuring out in the launcher if the Java is 64-bit or not means running 'java -version' and grepping "64-bit" from the output which can take from hundreds of miliseconds up to second(s). On the other hand increasing MaxPermSize to 384m even for a 32-bit process should still be OK, so I suggest to set -J-XX:MaxPermSize=384m statically in netbeans.conf. Unless anyone has arguments or different measurements against it, I will integrate this change. I agree. Thanks, Vladimir. Integrated into 'main-golden', will be available in build *201010251131* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/2c5a6d3c4472 User: Jesse Glick <jglick@netbeans.org> Log: Resurrected. Not currently run by default, but useful for investigating e.g. #190336. -J-XX:MaxPermSize=384m core-main #86f3f94551e6 Integrated into 'main-golden', will be available in build *201010270000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/86f3f94551e6 User: Antonin Nebuzelsky <anebuzelsky@netbeans.org> Log: #190336: increase MaxPermSize to 384m for 7.0. |