Conditional moves vs. branching in unrolled loops

[Remi Forax]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Paul Sandoz" <paul.sandoz at oracle.com>
> Cc: "hotspot compiler" <hotspot-compiler-dev at openjdk.java.net>
> Envoyé: Mercredi 6 Janvier 2016 02:05:56
> Objet: Re: Conditional moves vs. branching in unrolled loops
> 
> Darn, this works against the "say what you mean" story I told for checkIndex.
> 
> The bug here is very very special but is hit commonly so needs fixing. The
> special part is that accumulating Math.max values over a long loop almost
> *always* creates a series of predictable branches, which means cmov will
> lose on many CPUs places. (Exercise: Try to construct a long series of
> values for which each value is the largest so far, randomly, with 50%
> probability.  This will not be a series found often in nature.)
> 
> We need to explicitly detect accumulations on cmov ops in long loops, and
> convert them to branches.
> 
> Also, we should continue to recommend using intrinsics instead of random
> logic.
> 
> Fun fact:  Using your own branch logic makes the JVM manage a branch profile
> just for you, which can mean performance. Intrinsics, if they have internal
> branch logic, have polluted profiles. We need better call-site profiles
> and/or split profiles to overcome this.

we already have the first part of a kind of split profiles in tiered mode,
if code is first inlined by c1, c2 could use these different profiles,
but currently the profiles are shared because you have one profile for one bci.

so in tiered more, we should have one profile by bci + caller path inside the same inlining blob,
the VM need to keep the inlining tree created by c1 to send it to c2
(there is maybe enough info in the stackwalk info to recreate the inlining tree). 

> 
> – John

Rémi

> 
> > On Jan 5, 2016, at 4:47 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> > 
> > 
> >> On 5 Jan 2016, at 13:00, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> >> 
> >> This is a known issue: https://bugs.openjdk.java.net/browse/JDK-8039104
> > 
> > Many thanks, i closed JDK-8146071 as a dup of JDK-8039104.
> > 
> > Paul.
>