Receive the following exceptions at startup and randoom times when attempting to use the Garbage First Garbage Collector
provided in the 1.7.0 and 1.6.0_14 builds for testing:
For instance, this is a cut and paste from the attached log file
While scanning: jar:file:/C:/server/8.0.050/ptc_compileagainst/Windchill_8.0/codebase/lib/JGL.jar!/
Caused: java.lang.AssertionError: Pool: Code Cache Type: Non-heap memory TresholdSupported: true
[catch] at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.scanRoots(RepositoryUpdater.java:1798)
Created attachment 76881 [details]
Log file with exceptions
*** Issue 158459 has been marked as a duplicate of this issue. ***
*** Issue 158795 has been marked as a duplicate of this issue. ***
*** Issue 159170 has been marked as a duplicate of this issue. ***
*** Issue 158613 has been marked as a duplicate of this issue. ***
The error basically means that there is no heap memory pool that would support usage threshold. The IDE uses the usage
threshold to optimally use memory during refactoring and indexing, while preventing OutOfMemoryErrors. If the usage
threshold is not supported, there are three options for the IDE: run the refactoring/indexing slowly, use the memory and
risk OOMEs or refuse to work. I personally think that the last option is the mosts appropriate one (better than be slow
or throw random OOMEs). What should be done, IMO:
-make the IDE fail more gracefully (explain to the user that it cannot run without usage threshold)
-check whether the G1GC will support the usage threshold in the future
*** Issue 161806 has been marked as a duplicate of this issue. ***
Build: NetBeans IDE Dev (Build 200905110201)
VM: Java HotSpot(TM) Client VM, 14.0-b15, Java(TM) SE Runtime Environment, 1.6.0_14-ea-b06
OS: Windows XP, 5.1, x86
Startup after upgrading to latest daily
java.lang.AssertionError: Pool: Code Cache Type: Non-heap memory TresholdSupported: true
Created attachment 81917 [details]
I would vote for 1 or 2 with a warning.
I would rather warn me that it may have a problem and try to work than give up.
Since 6 Update 14 just released...
I suspect this needs to be bumped up in priority.
*** Issue 166582 has been marked as a duplicate of this issue. ***
I think we have to mention this in release notes, just because we are going to bundle NB with JDK 6u14 and unfortunately
people will try to use G1 GC ;(
Proposed text :
# Difficulties using IDE with G1 Garbage Collector (issue 158421)
Description: Using G1 Garbage Collector (in JDK 6u14 and higher and JDK7), you may encounter exceptions thrown while
Workaround: Do not use G1 GC (remove -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC from netbeans.conf or command line)
David/Honza/Rasta please check the proposed text. Thanks in advance.
I agree with Jan that the IDE should die right after start with an informative message.
I also agree with the proposed wording to the release notes.
I agree with release note too.
Running without monitoring of available memory is risky. So, we should notify user about this RN and shut down IDE.
Might be better to create a page on the wiki and put a link to the wiki to the release notes instead of the link to this
bug (that could be included on the wiki). This would allow us to provide up-to-date information to the users and would
not force them to read whole bug.
I did some experiments and shutting down the IDE is a bit more difficult now due to ergonomics (the java.source module
is not enabled on the first start). I tried throwing an IllegalStateException from ModuleInstall.validate (will attach a
patch), but that does not seem to work well when a J2SE project is opened (throws NoClassDefFoundErrors). Starting the
IDE and creating a new J2SE Project work reasonably (although the user experience is not perfect). The check itself
takes ~4ms on my computer.
Note that there are several other LowMemoryNotifiers: one in each of csl.api, gsf and cnd.modelimpl. We may need to put
the check into some common module (or adjust all these modules).
Created attachment 83228 [details]
Trying to throw ISE from ModuleInstall.validate.
There is another check for isUsageThresholdSupported in LMListener in parsing.api (this was causing the NoClassDefFounds
while opening the projects). I tried to put the check into the parsing.api's ModuleInstall and it seems to work
reasonably. Unless someone strongly disagrees, I will commit that check into the trunk, so that it can be tested. Should
help at least with java.source and csl.api.
this functionality is disabled in cnd.modelimpl for 6.7, so shouldn't be a problem with CND
parsing.api should now complain and refuse to work when the memory usage threshold capability is missing:
Lets see what will be the experience with this patch.
ranbato, I still think this is the most viable option, sorry.
If this is the best solution based on the code, I understand.
It would just be nice (since as noted above people would have to turn this on manually anyway) to throw up a warning and
let them proceed 'at their own risk'.
Integrated into 'main-golden', will be available in build *200906081401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jan Lahoda <email@example.com>
Log: #158421: the IDE needs support for memory usage threshold - adding check to ensure the VM supports it.
I would prefer to fix this in NB 6.7 (means do not allow to run the IDE with G1 turned-on ... as described by jlahoda -
this may cause a lot of problems).
BTW: tested in trunk ... check works fine. Worse thing is that user can push "Disable Modules and Continue", the IDE
starts but she would be not able to create any project/use IDE at all.
Jan, will you push it to the release67 branch or should I do it? Thanks for the fix!
I can fix it in NB6.7. Is the current message/text OK, or should it be improved? Regarding the possibility to disable
the modules: we could try not to use ISE from the ModuleInstall, but rather show a custom dialog (like project.ant does
if it detects an incompatible version of Xalan). This would prevent the user from disabling the modules. I am however a
bit afraid of possible interactions with dynamic module enablement (ergonomics). So I would rather use the current trunk
fix for NB6.7, unless this problem is considered very important.
Fix is OK in my opinion.
Honza also created a page http://wiki.netbeans.org/NoMemoryUsageThreshold
verified in trunk, you can port the fix to 67release
Honza, please proceed with transplate into release67 ... thanks in advance.
Created attachment 83405 [details]
Final patch for release 6.7 (contains a link to wiki)
Please push it to the release67 repo ... Thanks.
Integrated into 'main-golden', will be available in build *200906110201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jan Lahoda <firstname.lastname@example.org>
Log: #158421(cont'd): the error message shows a link to the wiki, instead of a link to the issuezilla.
verified in RC3
*** Issue 166995 has been marked as a duplicate of this issue. ***