United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7087727 JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use
JDK-7087727 : JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use

Details
Type:
Bug
Submit Date:
2011-09-07
Status:
Closed
Updated Date:
2012-03-22
Project Name:
JDK
Resolved Date:
2012-01-23
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs23 (b06)

Related Reports
Backport:
Backport:
Duplicate:

Sub Tasks

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

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
                                     
2011-11-04
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
#
                                     
2011-11-07
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.
                                     
2011-11-07
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)
                                     
2011-11-07
SUGGESTED FIX

http://cr.openjdk.java.net/~twisti/7087727/
                                     
2011-11-09
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/83d0b5cd1438
                                     
2011-11-09
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/83d0b5cd1438
                                     
2011-11-15
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/83d0b5cd1438
                                     
2011-11-29
EVALUATION

See main CR
                                     
2011-11-30
EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/83d0b5cd1438
                                     
2012-03-22



Hardware and Software, Engineered to Work Together