17 Sep
2009
17 Sep
'09
10:39 p.m.
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