4 ms·

IIRC the JVM optimizes very aggressively based on runtime profile, and just adds traps to the optimized-out paths to collect new runtime profile. Imagine code

by madisp 7y ago

IIRC the JVM optimizes very aggressively based on runtime profile, and just adds traps to the optimized-out paths to collect new runtime profile. Imagine code like this, where at runtime foo is always null if (foo != null) { foo.bar(); foo.baz(); } if foo is always null the compiler will just remove all of the statements inside and places a trap there. If foo happens to be non-null (say, due to external environment changes) then the it hits the trap and the whole method is deoptimized and goes through the profiler again. The optimizations in the JVM are quite fascinating - https://advancedweb.hu/profile-based-optimization-techniques-in-the-jvm/ https://advancedweb.hu/profile-based-optimization-techniques... I imagine javascript engines employ similar techniques

chris1993 7y ago
The runtime optimisations are remarkable but it does look like runtime performance can change unpredictably. Has this been your experience?
- saagarjha 7y ago
  Yes, the JVM tends to speed up over time as it applies these optimizations.
- MaxBarraclough 7y ago
  A fair question. In principle this can happen, and HotSpot can respond to changes in the program's execution patterns, but to my knowledge it's not a problem in practice with real-world Java servers. Other than a 'warming up' phase, real-world performance doesn't tend to vary wildly as time progresses. (Disclaimer: I've not done a great deal of real-world Java work.)
MaxBarraclough 7y ago
Another example: if MyClass is the only class that implements MyInterface, HotSpot can generate code that takes advantage of that assumption, removing vtable indirection in method-calls. If, later in the program's execution, the Java classloader loads another class which implements MyInterface, HotSpot will detect that the assumption it made earlier no longer holds. Having determined that the code it generated earlier is no longer safe, it will discard that code. I recall reading that in earlier versions of HotSpot, it was sometimes possible to improve performance by making your class 'final', enabling the JVM to remove indirection for method-calls. This is not true of the later versions of HotSpot, where it can use the technique described above to safely make optimisations based on tentative assumptions, giving you the same enhanced performance either way.
hinkley 7y ago
Even older than that, hotspot would in-line the common case for method dispatch in situations where there is one implementation or where one implementation dominates. (Kind of wonder if Spring would perform at all without it).

by madisp 7y ago

chris1993 7y ago

The runtime optimisations are remarkable but it does look like runtime performance can change unpredictably. Has this been your experience?

saagarjha 7y ago
Yes, the JVM tends to speed up over time as it applies these optimizations.
MaxBarraclough 7y ago
A fair question. In principle this can happen, and HotSpot can respond to changes in the program's execution patterns, but to my knowledge it's not a problem in practice with real-world Java servers. Other than a 'warming up' phase, real-world performance doesn't tend to vary wildly as time progresses. (Disclaimer: I've not done a great deal of real-world Java work.)

MaxBarraclough 7y ago

Another example: if MyClass is the only class that implements MyInterface, HotSpot can generate code that takes advantage of that assumption, removing vtable indirection in method-calls. If, later in the program's execution, the Java classloader loads another class which implements MyInterface, HotSpot will detect that the assumption it made earlier no longer holds. Having determined that the code it generated earlier is no longer safe, it will discard that code. I recall reading that in earlier versions of HotSpot, it was sometimes possible to improve performance by making your class 'final', enabling the JVM to remove indirection for method-calls. This is not true of the later versions of HotSpot, where it can use the technique described above to safely make optimisations based on tentative assumptions, giving you the same enhanced performance either way.

hinkley 7y ago

Even older than that, hotspot would in-line the common case for method dispatch in situations where there is one implementation or where one implementation dominates. (Kind of wonder if Spring would perform at all without it).