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
|
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)
|