The Bytecode Mumbo Jumbo
summary
Claims that the Java compiler defers real optimisation to the JVM and ART, demonstrated by disassembled bytecode with needless loads/stores and extra allocations; measurement shows boxing creates garbage and object-sorts scale much worse than primitive-sorts (big penalties on Nexus 5 and ART vs Dalvik differences). Tools used: javap/dexdump, dx and Jack. Concrete build: a YUV→RGB converter rewritten with fixed-point lookup tables runs measurably faster; Jack/minification produces different optimisations than javac/dx.
AI-written summary · about
chapters (21)
- 0:00Intro
- 2:04Or, for example, on Android
- 2:22but change is coming! Jack & Jill
- 2:52Let's focus on javac Javac vs other compilers
- 3:06javac Does not produce optimized code
- 3:32For this reason Java bytecode & operations are stack based
- 3:50Quick example Stack based integer addition
- 6:08Java VM (JVM) All optimizations are left to be done by the JVM
- 8:23On Android there is jack to the rescue...
- 8:44And on Java there is the JIT compiler to the rescue
- 9:01Language additions Thinks to consider
- 12:54Autoboxing What about Jack?
- 13:53Language Additions Use them wisely!
- 14:18Difference between sorting primitive types & objects
- 15:22Loops What is going on behind the scenes
- 20:58Loops Use arrays instead of lists
- 23:11Calling a method Is there an overhead?
- 24:58String concatenation alternatives
- 30:10Slightly optimized version precalc tables, fixed point operations, 2 pixels per loop...
- 31:10Lets compare: Normal, minified, minified with optimizations & jack
- 32:36Performance measurements Avoid doing multiple tests in one run JIT might be evil!
related talks
38mThe bytecode gobbledygook
51mExploring Java’s Hidden Costs
34mAndroid or the ART of Optimizing Java Code
55mCompilers. Dalvik. ART. And everything in between
49mTrash Talk
17mJack, Jill & Java 8
35mUnderstanding the Kotlin to Dalvik bytecode translation
42mUnderstanding the Kotlin to Dalvik bytecode translation