4 ms·
I sort of understand how deoptimization works in general but I'm not sure how the JVM can use those methods to detect when a constant changes. Say you have code
by a-priori 15y ago
I sort of understand how deoptimization works in general but I'm not sure how the JVM can use those methods to detect when a constant changes. Say you have code like the following:
GRAVITY = 9.81
def g_force(mass):
GRAVITY * mass
At this point the JVM will aggressively optimize that method to inline the constant. If you later do:
GRAVITY /= 6 # we're on the moon now!
This change will affect the values of any computations that depend on the return value of g_force but should not affect which code paths get executed down the line. I'm probably missing something about how this mechanism works, but how would deoptimizing be triggered here?
- headius 15y agoI don't know the granularity on which the deoptimization guards get inserted, but the basic idea would be that if the constant changes, any code running that depended on the value of that constant will have to deoptimize. In your example, we would never enter the optimized code path without knowing that the constant's still the same as last time. Since no loop is emitted, there's no deoptimization mid-loop required. So we either run the optimized code, or we never get to the optimized code. If a deopt is required mid-loop, Hotspot inserts a "trap" that would see the deopt command and immediately branch to the interpreter with the current state. Of course there's limits to how far optimization can go, but having a way to tell Hotspot that there's a known-immutable constant object reference at this point in the code opens up a lot of opportunities.