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.
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 at org.netbeans.modules.java.source.util.LowMemoryNotifier.initJMX(LowMemoryNotifier.java:147) at org.netbeans.modules.java.source.util.LowMemoryNotifier.addLowMemoryListener(LowMemoryNotifier.java:100) at org.netbeans.modules.java.source.usages.BinaryAnalyser.start(BinaryAnalyser.java:141) [catch] at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.scanRoots(RepositoryUpdater.java:1798) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.access$2700(RepositoryUpdater.java:1292) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker$1.run(RepositoryUpdater.java:1443) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker$1.run(RepositoryUpdater.java:1335) at org.netbeans.modules.java.source.usages.ClassIndexManager.writeLock(ClassIndexManager.java:99) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.run(RepositoryUpdater.java:1332) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.run(RepositoryUpdater.java:1292) at org.netbeans.api.java.source.JavaSource$CompilationJob.run(JavaSource.java:1618) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619)
Created attachment 76881 [details] Log file with exceptions
Reassign..
*** 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 User Comments: Startup after upgrading to latest daily Stacktrace: java.lang.AssertionError: Pool: Code Cache Type: Non-heap memory TresholdSupported: true at org.netbeans.modules.java.source.util.LowMemoryNotifier.initJMX(LowMemoryNotifier.java:147) at org.netbeans.modules.java.source.util.LowMemoryNotifier.addLowMemoryListener(LowMemoryNotifier.java:100) at org.netbeans.modules.java.source.usages.BinaryAnalyser.start(BinaryAnalyser.java:146) at org.netbeans.modules.java.source.indexing.JavaBinaryIndexer$1.run(JavaBinaryIndexer.java:83) at org.netbeans.modules.java.source.indexing.JavaBinaryIndexer$1.run(JavaBinaryIndexer.java:70) at org.netbeans.modules.java.source.usages.ClassIndexManager.writeLock(ClassIndexManager.java:100)
Created attachment 81917 [details] stacktrace
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. ***
Rasta/David ... 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 using IDE. 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: http://hg.netbeans.org/jet-main/rev/cea8c226c1d5 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) Changeset: http://hg.netbeans.org/main-golden/rev/cea8c226c1d5 User: Jan Lahoda <jlahoda@netbeans.org> 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 thanks
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.
http://hg.netbeans.org/release67?cmd=changeset;node=6912c1b3475d
Integrated into 'main-golden', will be available in build *200906110201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/6063da7c17b1 User: Jan Lahoda <jlahoda@netbeans.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. ***