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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
