[9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

[John Rose]

On Oct 10, 2014, at 2:20 PM, Remi Forax <forax at 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.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20141011/0078cfa7/attachment-0001.html>