Too bad Groovy isn't in here: "Alternative Languages on a JVM" http://www.azulsystems.com/events/javaone_2009/session/2009_J1_JVMLang.pdf ...
Deeper Dive
Clojure - “almost close”
● Good: no obvious subroutine calls in inner loop ● Bad: Massive “ephemeral” object allocation - requires good GC ● But needs Escape Analysis to go really fast ● Ugly: fix-num overflow checks everywhere ● Turn off fix-nums: same speed as Java ● Weird “holes” - ● Not-optimized reflection calls here & there ● Can get reports on generated reflection calls 10 Deeper Dive
Jython - “almost close”
● Also has fix-num issue; massive allocation ● Some extra locks thrown in
JavaScript/Rhino - “almost close”
● All things are Doubles – not 'double' ● Same fix-num allocation issues as Clojure, Jython ● Otherwise looks pretty good (no fix-num checks)
JRuby – Missed The Metal
● Assuming CachingCallSite::call inlines ● Using -XX:+PrintInlining to determine ● But flag is lying: claims method inlined, but it's not 11 Common Issue – Fix-Nums
Huge allocation rate of “fix-nums”
● Allocation is not free ● Setting final fields cost a memory fence ● GC does NOT cost here ● i.e., object pooling would be a big loser
Could do much better with JIT
● Need “ultra-stupid” Escape Analysis ● Need some (easy) JIT tweaking ● e.g. Getting around Integer.valueOf(i) caching 12 JRuby – Missed The Metal
Each minor action dispatches via “call”
Assuming CachingCallSite::call inlines
● (and allows further inlining)
Using -XX:+PrintInlining to determine
But flag is lying: claims inlined, but it's not
● BimorphicInlining is 'guessing' wrong target
Confirmed w/GDB on X86 Java6
Confirmed w/Azul profiler
● My 1st impression: can't be inlined ever Niels http://nielsmayer.com