New subject: [xwiki-devs] interesting comparison of scriping languages for Java from JavaOne

17 Sep 2009

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