JDK-7087727 : JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-09-07
  • Updated: 2012-03-22
  • Resolved: 2012-01-23
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 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Duplicate :  
JDK-7087728 - crash in C2 code if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use
Description
The flag setting ScavengeRootsInCode=2 causes the JIT to inline more constants.  This is generally a good thing for performance, but can cause bugs in compiled code.

In the attached code, there is a crash when the second benchmark runs.  (The first benchmark completes with doubled speed, compared with the default setting of ScavengeRootsInCode=1.)

By fixing this bug and similar blocking bugs, we should be able to turn ScavengeRootsInCode=2 by default.
Comments
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/83d0b5cd1438
22-03-2012
EVALUATION See main CR
30-11-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/83d0b5cd1438
29-11-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/83d0b5cd1438
15-11-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/83d0b5cd1438
09-11-2011
SUGGESTED FIX http://cr.openjdk.java.net/~twisti/7087727/
09-11-2011
EVALUATION The problem is at BCI 24: (dbx) p parse_method->print() <ciMethod name=run holder=nashorn292usecases/Nashorn292UseCases$UseCase signature=()V loaded=true flags=DEFAULT_ACCESS ident=714 PERM address=0x83a3920>parse_method->print() = (void) (dbx) p parse_method->print_codes() 0 getstatic 27 <nashorn292usecases/Nashorn292UseCases.USE_CONSTANT_METHOD_HANDLES/Z> 3 ifeq 13 0 bci: 3 BranchData taken(0) displacement(52) not taken(48350904) 6 fast_aload_0 7 invokevirtual 28 <nashorn292usecases/Nashorn292UseCases$UseCase.getConstantMethodHandle()Ljava/lang/invoke/MethodHandle;> 16 bci: 7 VirtualCallData count(0) entries(2) 'nashorn292usecases/Nashorn292UseCases$UseCase1'(34094 0.00) 'nashorn292usecases/Nashorn292UseCases$UseCase2'(48319473 1.00) 10 goto 17 40 bci: 10 JumpData taken(48353859) displacement(12) 13 aload_0 14 getfield 23 <nashorn292usecases/Nashorn292UseCases$UseCase.dynamicInvoker/Ljava/lang/invoke/MethodHandle;> 17 astore_1 18 fast_aload_0 19 aload_1 20 fast_aaccess_0 21 fast_agetfield 29 <nashorn292usecases/Nashorn292UseCases$UseCase.input/Ljava/lang/Object;> 24 invokevirtual 30 <java/lang/invoke/MethodHandle.invokeExact(Ljava/lang/Object;)Ljava/lang/Object;> 52 bci: 24 VirtualCallData count(48354697) entries(0) 27 fast_aputfield 31 <nashorn292usecases/Nashorn292UseCases$UseCase.output/Ljava/lang/Object;> 30 return parse_method->print_codes() = (void)
07-11-2011
EVALUATION $ java -XX:+UnlockDiagnosticVMOptions -XX:ScavengeRootsInCode=2 -DUSE_CONSTANT_METHOD_HANDLES=true nashorn292usecases.Nashorn292UseCases VM option '+UseParallelGC' VM option '+PrintGC' VM option '+UnlockDiagnosticVMOptions' VM option 'ScavengeRootsInCode=2' (null loop kernel) 730 ms (null loop kernel) 661 ms (null loop kernel) 661 ms (null loop kernel) 661 ms (null loop kernel) best = 661 ms #1 2939 ms #1 2938 ms #1 2940 ms #1 2939 ms #1 best = 2938 ms END # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/callGenerator.cpp:786 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/ct232829/hsx/hotspot-comp/7087727/src/share/vm/opto/callGenerator.cpp:786), pid=17843, tid=21 # assert(bc == Bytecodes::_invokedynamic) failed: must be # # JRE version: 8.0-b12 # Java VM: Java HotSpot(TM) Server VM (23.0-b03-internal-jvmg mixed mode solaris-x86 ) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/ct232829/hsx/hotspot-comp/7087727/hs_err_pid17843.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp #
07-11-2011
EVALUATION The test case has a code pattern that looks similar to the selectAlternative idiom but boils down to a different invoke bytecode (invokevirtual in that case). The current code in PredictedDynamicCallGenerator::generate checks for invokespecial (which is used by selectAlternative) and so code for invokedynamic is generated (in non-debug builds) which eventually leads to a crash.
07-11-2011
EVALUATION A JPRT run with ScavengeRootsInCode=2 passed: VM test flags: -XX:+UnlockDiagnosticVMOptions -XX:ScavengeRootsInCode=2 Run time: 02H 12m 34s Build Stats: 39 pass, 0 fail, 0 killed, 0 working, 0 initializing, 0 not started Test Stats: 502 pass, 0 fail, 0 killed, 0 working, 0 initializing, 0 not started
04-11-2011