Fixnums: last mile for JRuby math perf

[Charles Oliver Nutter]

FYI, given the upstart MagLev Ruby implementation (described below), I 
have a newfound respect for the proposed "fixnums in the VM" MLVM 
enhancement. On several benchmarks, especially those related to math, 
the constant fixnum churn has now started to become the primary 
bottleneck. Beyond that, our custom fixnum type obviously stands neatly 
in the way of several optimizations that could be applied to fixnums in 
general.

Reading through John Rose's "fixnums" article, it doesn't sound like 
adding fixnums would be very easy, though it certainly doesn't sound 
impossible either. I was mostly curious if anyone on this list has an 
interest (and more importantly, the necessary skills) in pursuing fixnum 
support in MLVM. And I know John and other Sun folks are in perpetual 
"swamped" mode, but I'd also like to hear if this ranks at all on lists 
of MLVM/DVM priorities inside Sun.

MagLev is a very new, unreleased, untested, incomplete Ruby 
implementation from GemStone based on their SmallTalk VM. In early, 
unofficial results, it positively spanks the other implementations 
(including JRuby) on fixnum/math-heavy benchmarks, largely because (I 
assume) they have true fixnum/SmallInteger support at a VM level. Now I 
seriously doubt that the majority of Ruby applications depend on 
superfast math, given the relative ease in which someone can bail out to 
an extension language like C or Java, but there are plenty of mundane 
operations where true fixnums would really be handy (e.g. simple loops, 
array indexing, etc).

FWIW, Ruby 1.8 and 1.9 use tagged integers for fixnum, and JRuby still 
outperforms both of them with a custom boxed reference type. This is 
almost certainly due to other parts of JRuby being substantially faster 
than either implementation, but I tremble to think what real fixnum 
support in the VM might do. And in my primitive experiments, a 
hand-written Java fib using our fixnum type for all integer operations 
performed no better than normal, dynamic-dispatched, compiled Ruby code 
in JRuby with all optimzations turned on, so we've pretty much turned 
execution and dispatch performance up as high as they can go without 
unboxing fixnum itself (which we will not do, given the monumental task 
of supporting additional primitive call paths).

On a side note: any recommendations for optimizing fixnums on current 
JVMs? A few immediate ideas come to mind: fixnum cache (which we already 
have for -128..127), heavier memory ratios toward "newer" generations, 
and in general trying to reduce fixnum churn where possible (literal 
caches, static analysis to find unneded constructions...). Comments on 
these and others?

- Charlie