The document discusses performance testing of various programming languages running on the Java Virtual Machine (JVM). It describes running a simple looping benchmark in Java, Scala, Clojure, JRuby, JPC and JavaScript to see how well each language's bytecodes can be optimized by the JIT compiler. The results show that Java and Scala perform similarly due to similar semantics, while other languages encounter issues like object allocation, lack of inlining, or data type mismatches. The author advocates for tools to help language implementers understand JVM optimization barriers and ensure their languages can achieve high performance.

1. A Lock-Free Hash Table Fast Bytecodes for Funny Languages Dr. Cliff Click Chief JVM Architect & Distinguished Engineer blogs.azulsystems.com/cliff Azul Systems March 25, 2009

3. Bytecode patterns are different

5. Am I inlining?

9. Look at performance

10. Look at JIT'd code

22. And thus nearly direct translation to machine code

24. For this example: 16000 classes, 7800 compilations

25. But JIT falls down removing e.g. redundant X86 flag sets

26. Maybe fix by never storing 'flags' into memory

27. Also no fixnum issue

29. Bad: Massive “ephemeral” object allocation - requires good GC

30. But needs Escape Analysis to go fast

31. Ugly: fix-num overflow checks everywhere

32. Can turn off fix-nums; could be same speed as Java

35. Same allocation issues as Fixnum

36. Otherwise looks pretty good (no fixnum checks)

38. Could do much better w/JIT

39. Need ultra-stupid Escape Analysis

40. Need some (easy) JIT tweaking

42. Using +PrintInlining to determine

47. JIT removes trampoline

48. Possibly inlines

50. No inlining during profiling

51. Profiling confuses callers per callsite

53. No inlining during profiling

54. Profiling confuses callers per callsite

56. No attempt at guarded inlining

64. Break in w/GDB and – read the asm

65. Did translation go as you expected? (no?)

69. Clojure Traveling Salesmen Problem w/worker 'ants'

71. Less TOTAL throughput as more CPUs added

75. Thru-put cap expected, or maybe slow degrade – but rapid falloff!?!?

76. Maybe STM becomes “graceful under pressure” later

78. ..then down, then craters

79. Why does DB not queue requests & maintain max throughput?

82. So can predict performance as the min of max-thruput's...