Now throw in this complication. The JIT decided to convert
multiplication inside the loop to addition. There potentially needs to
be a fixup corresponding to each optimisation.
there are all sorts of optimizations which could break the simple case,
but what is to say that the JIT actually uses these optimizations in
these cases? (rather than limiting itself solely to "reasonably safe"
optimizations in such cases).
or, alternatively, it could just mark the point where it will jump into
the code as a "synchronized label" or simiar, so regardless of what
sorts of optimizations are used elsewhere, everything is "consistent" at
the location where it will jump into the JITed code (at the potential
cost of a register spill just before this entry point for all subsequent
executions, ...).
but, absent more information, it starts to get pointless to speculate.
but, hell, with certain compilers (*cough* MSVC *cough*), it is an
optimization setting mostly to have it cache the values of variables in
registers (much less anything much more advanced that this).
caching variables in registers and using basic peephole optimizations
actually goes a long ways towards generating "optimized" compiler output.
many other (potentially more significant) optimizations are
higher-level, and don't necessarily actually make much of a difference
at the lower-levels.
....