JDK-7049122 : unit test java/lang/invoke/RicochetTest.java with MAX_ARITY=255 sometimes triggers 7009641
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-05-27
  • Updated: 2020-07-20
  • Resolved: 2011-07-18
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 Availability Release.

To download the current JDK release, click here.
JDK 7
7 b145Fixed
Related Reports
Relates :  
JDK-7009641 - Don't use CodeCache for allocations if it is already full
Relates :  
JDK-8249697 - remove temporary fixes from java/lang/invoke/RicochetTest.java
Description
The log is:

java.lang.Exception: JUnit test failure
        at com.sun.javatest.regtest.JUnitAction$JUnitRunner.main(JUnitAction.java:99)
        at com.sun.javatest.regtest.JUnitAction$JUnitRunner.main(JUnitAction.java:77)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
        at java.lang.Thread.run(Thread.java:722)

JavaTest Message: Test threw exception: java.lang.Exception: JUnit test failure
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.Exception: JUnit test failure
result: Failed. Execution failed: `main' threw exception: java.lang.Exception: JUnit test failure


test result: Failed. Execution failed: `main' threw exception: java.lang.Exception: JUnit test failure

Reproducible on solaris-sparc with VM options '-client -Xcomp -XX:+StartAttachListener -XX:+UseConcMarkSweepGC'.

Another log seen is:

----------System.out:(16/898)----------
[testFilterObject]
[testFilterObject done]
[testFilterInteger]
[testIntSpreads]
[testByteSpreads]
[testLongSpreads]
Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
Code Cache  [0x00002aaaab54d000, 0x00002aaaae54d000, 0x00002aaaae54d000)
 total_blobs=10470 nmethods=1654 adapters=8767 free_code_cache=44Kb largest_free_block=1344
[testIntCollects]
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 4104 bytes for CodeCache: no room for vtable chunks
# An error report file with more information is saved as:
# /export/local/81230.JDK7.PROMOTION.VM+linux-amd64_javase__server_comp_JT_JDK_java_lang/results/workDir/java/lang/invoke/RicochetTest/hs_err_pid8987.log
----------System.err:(0/0)----------
result: Failed. Unexpected exit from test [exit code: 1]


test result: Failed. Unexpected exit from test [exit code: 1]
Comments
EVALUATION See main CR
04-06-2011
SUGGESTED FIX Specific proposed fix for JDK7 b145: Reduce the MAX_ARITY of the stress test to 50, until 7009641 is fixed. (7009641 is targeted to 8-pool at present.) This will remove a significant source of noise from our nightlies.
03-06-2011
SUGGESTED FIX We will file a low-pri bug to deal with the actual crash, which is a pre-existing condition. We will reduce the scope of the stress tests, to arity 50 instead of arity 255. When the crasher is fixed, we may increase the stress tests. There is also a performance issue, since the stress tests can be slow to run, potentially causing test failures due to timeouts.
01-06-2011
EVALUATION I think this is just the expected result of running with so many signatures. As far as I can tell they are being properly reused but in 64 bit the opportunities for reuse are more limited so it takes around 10000 adapters to run the test while in 32 bit it only takes around 3500. The reason is that in 32 bit int and Object arguments smear together but in 64 bit they don't and they can't smear with long either because longs are handled differently in the interpreter. The adapters can be very large as well with the bigger ones being 4k in length. The adapters actually handle running out of space in the code cache properly but the vtable code doesn't so the particular crash here is 7009641 which should be handled more gracefully.
01-06-2011
EVALUATION Heavy compilation of method handles (via -Xcomp) creates many adapters of type methodOopDesc. For a likely creation point, see MethodHandleCompiler::get_method_oop. These adapters are permanent, so if there is an excessive number of them they can blow the heap, in theory. But something more is probably going on, since the number of such adapters should not scale beyond the program size, and these programs are relatively small. Probably adapters are being redundantly created and not reused. The test in question exercises many signatures at once, along with -Xcomp. (It specifies MAX_ARITY=255.) The internal algorithms may have a quadratic blowup if adapters are not properly reused. Still, this should not blow the heap. Needs investigation.
27-05-2011