5 ms·

> I understood the JVM does an dynamic analysis of the code when running, so it can compile to better performance. The argument that JIT having more informatio

> I understood the JVM does an dynamic analysis of the code when running, so it can compile to better performance. The argument that JIT having more information and therefore should/could be able to produce better code never really materialized in most the of mainline JITs (JVM,.net etc...). From my point of view, there is a lot of reasons for this : - Most VM starts with higher level languages than native systems. And most of the "runtime informations" is not used to produce faster "native code" as used to efficiently deconstructs some of the higher abstractions (think devirtualization, unboxing, moving stuff from the heap to the stack etc...) - Because Jitting happens at runtime, most jit shy away from complex compiler transformations : So you have more runtime information but less time to actually do something useful with that information. - Tracking, recording, updating and all the booking involve in collecting any runtime information also limit "quality" of the profile in practice further more reducing their impact. > I guess the author is talking about this type of things I don't think so, the author is probably talking about optimization which lowers higher level constructs, like unboxing etc...

_old_dude_ 9y ago
You have forgotten several important analysis routinely done by JITs that significantly speedup Java: - deep inlining, by default the inlining depth of a JVM is around 10, you can not have this depth of inlining with a statically compiled language. - prune non taken branches (and exception blocks), so you do not fill the instruction cache with code never executed. - branch re-ordering, the code executed more often can be read from top to bottom, less executed code is offloaded to a side block. - CPU instructions selection at runtime. - lock profiling, generate different codes if the lock is contented or not. BTW .Net do not do any code profiling, so can not use most of these optimizations.
mike_hearn 9y ago
The argument that JIT having more information and therefore should/could be able to produce better code never really materialized in most the of mainline JITs Disabling JIT PGO in HotSpot loses you 15-20% performance, so I think it did materialise. Because Jitting happens at runtime, most jit shy away from complex compiler transformations I wonder what you classify as complex? Escape analysis driven scalar replacement, PICs, superword optimisations, lock elimination, automatic hardware transactional memory usage all seem very complex to me. HotSpot uses two JITs to trade off speed vs complexity, C1 does a very fast compile with only fast optimisations, C2 will revisit very hot methods and do the extensive optimisation of them.

_old_dude_ 9y ago

You have forgotten several important analysis routinely done by JITs that significantly speedup Java: - deep inlining, by default the inlining depth of a JVM is around 10, you can not have this depth of inlining with a statically compiled language. - prune non taken branches (and exception blocks), so you do not fill the instruction cache with code never executed. - branch re-ordering, the code executed more often can be read from top to bottom, less executed code is offloaded to a side block. - CPU instructions selection at runtime. - lock profiling, generate different codes if the lock is contented or not. BTW .Net do not do any code profiling, so can not use most of these optimizations.

mike_hearn 9y ago

The argument that JIT having more information and therefore should/could be able to produce better code never really materialized in most the of mainline JITs Disabling JIT PGO in HotSpot loses you 15-20% performance, so I think it did materialise. Because Jitting happens at runtime, most jit shy away from complex compiler transformations I wonder what you classify as complex? Escape analysis driven scalar replacement, PICs, superword optimisations, lock elimination, automatic hardware transactional memory usage all seem very complex to me. HotSpot uses two JITs to trade off speed vs complexity, C1 does a very fast compile with only fast optimisations, C2 will revisit very hot methods and do the extensive optimisation of them.