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.

Bug 158421 - [G1 GC from JDK 6.0u14/7] java.lang.AssertionError: Pool: Code Cache Type: Non-heap memory TresholdSupported: tru
Summary: [G1 GC from JDK 6.0u14/7] java.lang.AssertionError: Pool: Code Cache Type: No...
Status: VERIFIED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: PC All
: P1 blocker (vote)
Assignee: Jan Lahoda
URL: http://statistics.netbeans.org/except...
Keywords: RELNOTE
: 158459 158613 158795 159170 161806 166582 166995 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-02-11 20:56 UTC by jfderaismes
Modified: 2009-08-27 09:30 UTC (History)
11 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 152256


Attachments
Log file with exceptions (104.29 KB, text/plain)
2009-02-11 20:57 UTC, jfderaismes
Details
stacktrace (2.14 KB, text/plain)
2009-05-11 17:46 UTC, ranbato
Details
Trying to throw ISE from ModuleInstall.validate. (2.33 KB, patch)
2009-06-05 10:46 UTC, Jan Lahoda
Details | Diff
Final patch for release 6.7 (contains a link to wiki) (2.84 KB, patch)
2009-06-10 14:12 UTC, Jan Lahoda
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description jfderaismes 2009-02-11 20:56:51 UTC
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)
Comment 1 jfderaismes 2009-02-11 20:57:34 UTC
Created attachment 76881 [details]
Log file with exceptions
Comment 2 Max Sauer 2009-02-16 12:03:57 UTC
Reassign..
Comment 3 Jiri Prox 2009-02-26 11:08:10 UTC
*** Issue 158459 has been marked as a duplicate of this issue. ***
Comment 4 Jiri Prox 2009-02-26 11:09:35 UTC
*** Issue 158795 has been marked as a duplicate of this issue. ***
Comment 5 Jiri Prox 2009-02-26 11:11:00 UTC
*** Issue 159170 has been marked as a duplicate of this issue. ***
Comment 6 Rastislav Komara 2009-03-23 17:08:57 UTC
*** Issue 158613 has been marked as a duplicate of this issue. ***
Comment 7 Jan Lahoda 2009-03-23 19:59:17 UTC
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
Comment 8 Jan Lahoda 2009-04-05 18:52:20 UTC
*** Issue 161806 has been marked as a duplicate of this issue. ***
Comment 9 ranbato 2009-05-11 17:46:15 UTC
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)
Comment 10 ranbato 2009-05-11 17:46:20 UTC
Created attachment 81917 [details]
stacktrace
Comment 11 ranbato 2009-05-11 19:17:17 UTC
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.
Comment 12 ranbato 2009-05-29 18:19:18 UTC
Since 6 Update 14 just released...
I suspect this needs to be bumped up in priority.
Comment 13 Jan Lahoda 2009-06-05 09:28:35 UTC
*** Issue 166582 has been marked as a duplicate of this issue. ***
Comment 14 Marian Mirilovic 2009-06-05 09:51:42 UTC
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.
Comment 15 David Strupl 2009-06-05 10:02:03 UTC
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.
Comment 16 Rastislav Komara 2009-06-05 10:23:44 UTC
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.
Comment 17 Jan Lahoda 2009-06-05 10:44:51 UTC
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).
Comment 18 Jan Lahoda 2009-06-05 10:46:23 UTC
Created attachment 83228 [details]
Trying to throw ISE from ModuleInstall.validate.
Comment 19 Jan Lahoda 2009-06-05 11:51:20 UTC
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.
Comment 20 Vladimir Voskresensky 2009-06-05 12:11:32 UTC
this functionality is disabled in cnd.modelimpl for 6.7, so shouldn't be a problem with CND
Comment 21 Jan Lahoda 2009-06-05 15:14:21 UTC
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.
Comment 22 ranbato 2009-06-05 17:54:53 UTC
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'.
Comment 23 Quality Engineering 2009-06-08 18:45:51 UTC
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.
Comment 24 Marian Mirilovic 2009-06-09 09:50:43 UTC
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.
Comment 25 David Strupl 2009-06-09 10:00:20 UTC
Jan, will you push it to the release67 branch or should I do it? Thanks for the fix!
Comment 26 Jan Lahoda 2009-06-09 10:23:26 UTC
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.
Comment 27 Jan Jancura 2009-06-09 15:47:57 UTC
Fix is OK in my opinion.
Comment 28 Marian Mirilovic 2009-06-10 07:58:12 UTC
Honza also created a page http://wiki.netbeans.org/NoMemoryUsageThreshold
Comment 29 Jiri Prox 2009-06-10 11:09:17 UTC
verified in trunk, you can port the fix to 67release
thanks
Comment 30 Marian Mirilovic 2009-06-10 13:36:50 UTC
Honza, please proceed with transplate into release67 ... thanks in advance.
Comment 31 Jan Lahoda 2009-06-10 14:12:19 UTC
Created attachment 83405 [details]
Final patch for release 6.7 (contains a link to wiki)
Comment 32 David Strupl 2009-06-10 14:27:54 UTC
Please push it to the release67 repo ... Thanks.
Comment 34 Quality Engineering 2009-06-11 08:54:44 UTC
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.
Comment 35 Jiri Prox 2009-06-11 16:50:58 UTC
verified in RC3
Comment 36 Jan Lahoda 2009-08-27 09:30:25 UTC
*** Issue 166995 has been marked as a duplicate of this issue. ***