Ideally profile pollution could be solved/improved without requiring tiered; tiered has its own wrinkles, and many places simply use C2 alone.<div><br></div><div><br>On Tuesday, January 5, 2016, Remi Forax <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">----- Mail original -----<br>
> De: "John Rose" <<a href="javascript:;" onclick="_e(event, 'cvml', 'john.r.rose@oracle.com')">john.r.rose@oracle.com</a>><br>
> À: "Paul Sandoz" <<a href="javascript:;" onclick="_e(event, 'cvml', 'paul.sandoz@oracle.com')">paul.sandoz@oracle.com</a>><br>
> Cc: "hotspot compiler" <<a href="javascript:;" onclick="_e(event, 'cvml', 'hotspot-compiler-dev@openjdk.java.net')">hotspot-compiler-dev@openjdk.java.net</a>><br>
> Envoyé: Mercredi 6 Janvier 2016 02:05:56<br>
> Objet: Re: Conditional moves vs. branching in unrolled loops<br>
><br>
> Darn, this works against the "say what you mean" story I told for checkIndex.<br>
><br>
> The bug here is very very special but is hit commonly so needs fixing. The<br>
> special part is that accumulating Math.max values over a long loop almost<br>
> *always* creates a series of predictable branches, which means cmov will<br>
> lose on many CPUs places. (Exercise: Try to construct a long series of<br>
> values for which each value is the largest so far, randomly, with 50%<br>
> probability.  This will not be a series found often in nature.)<br>
><br>
> We need to explicitly detect accumulations on cmov ops in long loops, and<br>
> convert them to branches.<br>
><br>
> Also, we should continue to recommend using intrinsics instead of random<br>
> logic.<br>
><br>
> Fun fact:  Using your own branch logic makes the JVM manage a branch profile<br>
> just for you, which can mean performance. Intrinsics, if they have internal<br>
> branch logic, have polluted profiles. We need better call-site profiles<br>
> and/or split profiles to overcome this.<br>
<br>
we already have the first part of a kind of split profiles in tiered mode,<br>
if code is first inlined by c1, c2 could use these different profiles,<br>
but currently the profiles are shared because you have one profile for one bci.<br>
<br>
so in tiered more, we should have one profile by bci + caller path inside the same inlining blob,<br>
the VM need to keep the inlining tree created by c1 to send it to c2<br>
(there is maybe enough info in the stackwalk info to recreate the inlining tree).<br>
<br>
><br>
> – John<br>
<br>
Rémi<br>
<br>
><br>
> > On Jan 5, 2016, at 4:47 AM, Paul Sandoz <<a href="javascript:;" onclick="_e(event, 'cvml', 'paul.sandoz@oracle.com')">paul.sandoz@oracle.com</a>> wrote:<br>
> ><br>
> ><br>
> >> On 5 Jan 2016, at 13:00, Vitaly Davidovich <<a href="javascript:;" onclick="_e(event, 'cvml', 'vitalyd@gmail.com')">vitalyd@gmail.com</a>> wrote:<br>
> >><br>
> >> This is a known issue: <a href="https://bugs.openjdk.java.net/browse/JDK-8039104" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8039104</a><br>
> ><br>
> > Many thanks, i closed JDK-8146071 as a dup of JDK-8039104.<br>
> ><br>
> > Paul.<br>
><br>
</blockquote></div><br><br>-- <br>Sent from my phone<br>