On 10/11/2014 09:40 AM, John Rose wrote:
On Oct 10, 2014, at 2:20 PM, Remi Forax <fo...@univ-mlv.fr> wrote:

I have another question about inOptimizer(),
thinkint a little about it, if there is a code like
   if (unsafe.inOptimizer()) {
     ...
   }

this code will always trigger a recompilation, at least once, because in the 
interpreter, the branch will never be evaluated and in the JIT,
because inOptimizer will be rue, the JIT will insert a deopt instruction 
because the branch was never evaluated before.

I wonder if this recompilation can be avoided or not ?
I think so.  Being "in the optimizer" is not necessarily the same as being in 
compiled code.  If the JIT were going to deoptimize immediately after an inOptimizer=true 
condition, then it wasn't really in the optimizer at that point, or (to split hairs) it 
was at the very edge of partially-optimized code just about to fall out of it.

That's the reason we named it "inOptimizer" instead of "inCompiler".  The JIT 
is free to evaluate it to false, if the path is not well optimized.  The overall expectation is 
that as the code warms up, inOptimizer will go from false to true, eventually.

thanks for the explanation,
my mind was not able to see past the proposed implementation.


— John

Rémi

Reply via email to