JIT fixnum cases (with a value span <= 32) as a tableswitch

[kares]

... instead of falling back to lookupswitch

noticed (while fixing #4429) that only "perfect" consecutive fixnum cases generate a tableswitch

javac does some table/lookup space cost calc to decide, here just a simple size bound (of 32) is implemented

case 0, 10, 20, 30 will generate a table-switch (filling in 'wholes' e.g. case 1: default)
while case 0, 10, 50 will generate a lookup-switch just like before

[kares]

... feel free to postpone to next release if you feel like it could use some more work (e.g. a different max)

[enebo]

@kares It seems reasonable to me but I wonder how often this happens to warrant the extra code. I guess JVM does it so they thought it was worth it.

Second nit is you are still not putting your closing } onto same line :)

[kares]

yep, sorry about the style changes (although in this case I might have done it on purpose - the if () gets lost in dense lines bellow and above but I shall respect your style taste :).

since an update some time back my IDEA has never been the same - was glad to get the jruby project working again I need to spent some time setting it up as I need to manually undo changes it does for me.

will do a micro bench test whether its worth the change (should be since its expected to jump directly skiping the lookup part) -> will post back with numbers.
... such casing should be not that uncommon e.g. for def my(*args); methods

[olleolleolle]

Super-interesting deep-dive into a detail.

(Hi @kares, could you choose another name than p for a local variable in the Ruby tests?

My eyes – and some code highlighters – read that as Kernel#p.)

[kares]

thanks @olleolleolle ... sorry not into style updates really at this point (this code might get rejected).

have done some micro benchmarks previously (as @enebo suggested) and the change seemed only make a little difference, so I am not sure if tableswitch makes sense over lookupswitch if it 'complicates' code. but than maybe I have done it wrong - someone better understanding the difference in terms of JVM (and native code jitting) should decide whether this makes sense or not really ...

[headius]

This looks fine. Merging so it can bake for 9.1.9.0.