MRI adopts "jump table"-like optimization for case-when statement if all clauses have trivial immediate values such as Integer and Symbol

Is this documented somewhere? How does it interact with the existing semantics that cases are tried sequentially with =~? What if =~ has side effects? What if one case's =~ redefines =~ for a subsequent case?

If MRI does this then it's a language feature, not an optimisation, and it needs to be covered by the specs.

@mame we have some plans to reintroduce this at a later date. JRuby 1.7.x does a jump table for Fixnums and a couple of other simple types. We have not added them to 9k yet but we will at some point.

@chrisseaton

Is this documented somewhere?

Since this is an implementation detail of MRI, I don't think this behavior is documented anywhere.

How does it interact with the existing semantics that cases are tried sequentially with =~?

I think you meant ===. Whenever MRI evaluates trivial case statement, it checks if === of related classes is redefined or not, and cancels the optimization if any is redefined.

BTW, I have no intention to force you to do the same. This is just a suggestion.

@enebo Ah, do you mean this optimization has been already implemented but disabled for any reason? If so, sorry for noise. Thank you!

@mame it was not disabled, but we have a completely new runtime in JRuby 9000 so we could not just port the old optimization over as-is.

I understand very well. I'll try JRuby 1.7. Should I close this issue? May I leave it to you? Thank you very much!

We have an open issue for remaining optimizations in case/when, so we'll close this.

See #3513.

Reopening this as the better bug for ongoing optimization work.

FYI: I published my program and benchmark result.

@mame thanks for the link. We will be sure to reexamine the performance periodically and also once we re-add some jumptable optimizations.

@mame I have implemented constant-time Fixnum case/when but I'm getting a strange error running the --opt version of optcarrot:

[] ~/projects/optcarrot $ jruby -v -Xcompile.invokedynamic -Ilib bin/optcarrot --opt --benchmark examples/Lan_Master.nes
jruby 9.1.0.0-SNAPSHOT (2.3.0) 2016-04-05 2221210 Java HotSpot(TM) 64-Bit Server VM 25.60-b23 on 1.8.0_60-b27 +indy +jit [darwin-x86_64]
fps: 0
checksum: 27904
FiberError: can't yield from root fiber
      yield at org/jruby/ext/fiber/ThreadFiber.java:209
      yield at org/jruby/ext/fiber/ThreadFiber.java:200
        run at (generated PPU core):556
       sync at /Users/headius/projects/optcarrot/lib/optcarrot/ppu.rb:319
     update at /Users/headius/projects/optcarrot/lib/optcarrot/ppu.rb:254
  poke_2000 at /Users/headius/projects/optcarrot/lib/optcarrot/ppu.rb:344
       call at org/jruby/RubyMethod.java:127
        run at (generated CPU core):1478
       step at /Users/headius/projects/optcarrot/lib/optcarrot/nes.rb:42
        run at /Users/headius/projects/optcarrot/lib/optcarrot/nes.rb:77
      <top> at bin/optcarrot:6

Two questions:

1. What are fibers being used for in the generated code? Fibers are generally much more expensive in JRuby than in MRI since we have to use native threads to simulate them. If they can be eliminated from the optimized code, we may do better.
2. How can I look at the generated code?

Benchmark of 100 all-Fixnum cases (1000 does not JIT and remains interpreted):

[] ~/projects/optcarrot $ jruby -Xjit.threshold=0 bench_fixnum_case_when.rb 
  3.120000   0.040000   3.160000 (  1.925519)
  1.640000   0.010000   1.650000 (  1.485029)
  1.490000   0.000000   1.490000 (  1.491089)
  1.480000   0.000000   1.480000 (  1.480089)
  1.500000   0.010000   1.510000 (  1.503165)
  1.520000   0.000000   1.520000 (  1.533434)
  1.470000   0.000000   1.470000 (  1.458303)
  1.430000   0.000000   1.430000 (  1.440517)
  1.460000   0.000000   1.460000 (  1.454715)
  1.440000   0.000000   1.440000 (  1.443573)

[] ~/projects/optcarrot $ rvm jruby-9.0.5.0 do jruby -Xcompile.invokedynamic -Xjit.threshold=0 bench_fixnum_case_when.rb 
 79.910000   0.250000  80.160000 ( 78.924439)
 79.370000   0.200000  79.570000 ( 79.535567)
 79.720000   0.330000  80.050000 ( 80.274685)
 79.020000   0.200000  79.220000 ( 79.289017)
 78.380000   0.180000  78.560000 ( 78.604202)
 78.800000   0.190000  78.990000 ( 79.080842)
...

@mame @ko1 Can you point me toward the constant-time case/when optimization in MRI? I'd like to match it for JRuby 9.1.

@nobu You may know where this optimization is in MRI too...

There are some points in compile.c and insns.def.
Try git grep -i cdhash.

@nobu: Great, thanks!

@headius

1. What are fibers being used for in the generated code?

No fiber is used in the generated code. Maybe your jruby failed to generate a correct source code.

1. How can I look at the generated code?

Try jruby bin/optcarrot --opt --dump-ppu. Compare the output with normal ruby's output.

Continuing work in post 9.1.

Fixnum case optimizations have been merged to master. Remaining work bumped to 9.1.4.0.

General problem with large case statements preventing JIT. I'm detargeting.

There's nothing specific to case here that isn't covered by other bugs about large methods failing to compile. We know about that issue and the work required to solve it.

JRuby will optimize homogeneous case/when to a jump table in at least the Fixnum case, so we'll call this one done as of 9.1.4.0.