JDK-7174928 : JSR 292: unresolved invokedynamic call sites deopt and osr infinitely
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs23
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-06-06
  • Updated: 2013-07-31
  • Resolved: 2012-06-16
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
7u40Resolved 8Fixed hs23.2Fixed
Description
While testing a new flag I want to introduce (TraceOSR) I noticed that unresolved invokedynamic call sites compiled in C1 deoptimize and OSR infinitely.  The reason for that is we deoptimize but we don't have machinery in C1 to tell to throw the method out and recompile it.  So we just enter the same method again and hit the same unresolved call site.
Comments
Verified by comparing the performance of the benchmark suggested in the original bug comments in 7u40b31 and 7u4b15. Test: "jruby -J-showversion -J-d64 -J-XX:TieredStopAtLevel=1 -X+C bench_red_black.rb". Host: localhost, Windows 7, amd64.
31-07-2013
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e2fe93124108
29-06-2012
EVALUATION http://hg.openjdk.java.net/hsx/hsx23.2/hotspot/rev/ce8d9e20eded
20-06-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e2fe93124108
13-06-2012
EVALUATION Now the code sequence for an unresolved invokedynamic call site looks like this: 0xfffffd7ff6106d9a: mov %rsp,%rbp 0xfffffd7ff6106d9d: mov $0xfffffd7fd269bd28,%rsi ; {oop(cache [915] for constant pool [1576]/invokedynamic/operands[1798] for 'bench/bench_richards' cache=0xfffffd7fd269bd28)} 0xfffffd7ff6106da7: mov 0x6028(%rsi),%rsi 0xfffffd7ff6106dae: cmp $0x0,%rsi ;; 838 branch [EQ] [DeoptimizeStub: 0x479ca18] [bci:79] 0xfffffd7ff6106db2: je 0xfffffd7ff61095e6 0xfffffd7ff6106db8: mov 0x20(%rsi),%rsi ;*invokedynamic ; - bench.bench_richards::method__6$RUBY$release@79 (line 103) 0xfffffd7ff6106dbc: nop 0xfffffd7ff6106dbd: nop 0xfffffd7ff6106dbe: nop 0xfffffd7ff6106dbf: callq 0xfffffd7ff58cdd60 ; OopMap{off=3172} ;*invokedynamic ; - bench.bench_richards::method__6$RUBY$release@79 (line 103) ; {optimized virtual_call} 0xfffffd7ff6106dc4: mov %rbp,%rsp ;*invokedynamic ; - bench.bench_richards::method__6$RUBY$release@79 (line 103)
07-06-2012
SUGGESTED FIX Conditionally jump to the deopt stub in generated code if the CallSite object is null. Handling it this way it is not required to recompile the code.
07-06-2012
EVALUATION JRuby's red-black benchmark is one that suffers heavily from this bug. Fixing the problem shows a nice speedup: cthaling@intelsdv01:~/mlvm/jruby$ jruby -J-showversion -J-d64 -J-XX:TieredStopAtLevel=1 -X+C bench/bench_red_black.rb java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b41) Java HotSpot(TM) 64-Bit Server VM (build 24.0-b12, mixed mode) 17.83 GC.count = 1 17.301 GC.count = 2 17.39 GC.count = 3 17.5 GC.count = 3 17.408 GC.count = 4 17.439 GC.count = 5 17.252 GC.count = 6 17.43 GC.count = 7 18.086 GC.count = 7 17.71 GC.count = 8 cthaling@intelsdv01:~/mlvm/jruby$ jruby -J-showversion -J-d64 -J-XX:TieredStopAtLevel=1 -X+C bench/bench_red_black.rb java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b41) Java HotSpot(TM) 64-Bit Server VM (build 24.0-b12-internal, mixed mode) 7.099 GC.count = 1 6.967 GC.count = 2 6.821 GC.count = 3 6.925 GC.count = 3 6.884 GC.count = 4 6.812 GC.count = 5 6.772 GC.count = 6 6.996 GC.count = 7 6.929 GC.count = 7 6.807 GC.count = 8
07-06-2012