JDK-8000662 : NPG: nashorn ant clean test262 out-of-memory with Java heap
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.
The nashorn test
ant clean test262
fails with out-of-memory exception for the Java heap
We crash because of the 8003720 bug when we run the test262 test suite. We need to fix that before we push a fix for this bug.
This should be a P2 and I believe Coleen is currently working on this.
We don't understand how to fix this problem yet. We trying to get help from the 292 implementors to on fixing it.
I will try to get logs and hprofs on an ftp for you tomorrow
We will try increased heap sizes, but note that this breaks after ~200 tests. Not sure if there is enough heap size in the world to handle 11500 tests...
I've asked Marcus for the test case, instructions on how to run it, details of the machine (or machines) on which the OOME is seen, and some GC logs. A likely workaround is increasing the heap size temporarily - until the anonymous classloader issue is resolved.
1) clone a nashorn depot (ask Jim Laskey for access to Kenai project for Nashorn)
hg clone https://hg.kenai.com/hg/nashorn~source [nashorn-dir]
2) Clone the ecma test suite: hg clone Http://hg.Ecmascript.org/tests/test262 [test262-dir-on-your-hd]
3) ln -s [test262-dir-on-your-hd] [nashorn-dir]/nashorn/test/test262
4) cd [nashorn-dir]/nashorn
5) ant test262parallel
Boom (after about 200 tests). Hprof is full of method handles
Using b57 runs 11500 tests just fine.
Issue looks like it may be related to not cleaning up anonymous classes and classloaders.
FYI - this sort of blocks Nashorn. We have to remain on b57 (pre permgen removal) until this is fixed, and it also causes us development problems as then we can no longer test the bleeding edge invokedynamic performance fixes that the codegen team continuously check in.