[xwiki-devs] interesting comparison of scriping languages for Java from JavaOne
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
And the good news is that XWiki gives you the choice (velocity, groovy, python and ruby for now with others coming)! :) Thanks for the info -Vincent On Sep 17, 2009, at 10:39 PM, Niels Mayer wrote:
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
participants (2)
-
Niels Mayer -
Vincent Massol