Conditional moves vs. branching in unrolled loops
vitalyd at gmail.com
Wed Jan 6 12:43:36 UTC 2016
Ideally profile pollution could be solved/improved without requiring
tiered; tiered has its own wrinkles, and many places simply use C2 alone.
On Tuesday, January 5, 2016, Remi Forax <forax at univ-mlv.fr> wrote:
> ----- Mail original -----
> > 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
> > The bug here is very very special but is hit commonly so needs fixing.
> > 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
> > just for you, which can mean performance. Intrinsics, if they have
> > 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
> 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
> > – John
> > > On Jan 5, 2016, at 4:47 AM, Paul Sandoz <paul.sandoz at oracle.com
> > >
> > >
> > >> On 5 Jan 2016, at 13:00, Vitaly Davidovich <vitalyd at gmail.com
> > >>
> > >> This is a known issue:
> > >
> > > Many thanks, i closed JDK-8146071 as a dup of JDK-8039104.
> > >
> > > Paul.
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev