(no title)
pete23 | 10 years ago
http://insightfullogic.com/2014/May/12/fast-and-megamorphic-...
Worth noting also that Azul's Zing ReadyNow technology for AOT (and indeed their no-pause C4 collector) address some of the specific gripes raised here around the JVM...
jdmichal|10 years ago
fmstephe|10 years ago
The driving force behind ReadyNow (as I understand it) was that many performance sensitive systems needed to be fast out of the gates on start up. This means that an interpreted->compiled->optimised-compiled transition was not acceptable.
Developers would try to solve this by running dummy data through the system before it was open to real traffic. But this had the unfortunate consequence that the JIT would optimise for dummy data only, including clever inlining at, apparently, monomorphic call sites etc. When real traffic flows into the system the JVM sees that its optimisations are no longer effective/valid. This would trigger a de-compilation/re-compilation of many code sites causing a very noticeable stutter.
Now we have ReadyNow. If you are really committed to Java or the JVM and you don't like these JIT stutters this is your solution. But this is an extra layer of complexity and another thing to be managed and another thing to fail. This is on top of your JVM, jar file soup you may already be struggling with.
I would prefer a good AOT compiler to remove this concern and give me quite good predictable performance. YMMV of course.
Sources
http://www.azul.com/products/zing/readynow-technology-for-zi...
https://groups.google.com/forum/#!searchin/mechanical-sympat...