[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-mlvm-dev
Subject:    Inlining heuristic trouble
From:       christian.thalinger () oracle ! com (Christian Thalinger)
Date:       2011-07-11 15:37:31
Message-ID: ED69F8BD-F007-4FE9-87E6-DF63702CF632 () oracle ! com
[Download RAW message or body]

On Jun 21, 2011, at 3:28 AM, John Rose wrote:
> On Jun 20, 2011, at 12:17 PM, Tom Rodriguez wrote:
> 
> > On Jun 18, 2011, at 5:15 AM, R?mi Forax wrote:
> > 
> > > On 06/18/2011 03:15 AM, Tom Rodriguez wrote:
> > > > On Jun 17, 2011, at 5:00 PM, John Rose wrote:
> > > > 
> > > > > On Jun 17, 2011, at 10:21 AM, Tom Rodriguez wrote:
> > > > > 
> > > > > > > Sorry, I was thinking recording which branch of the GWT is taken and
> > > > > > > storing them in the GWT.
> > > > > > > Two GWTs should not share the same metadata.
> > > > > > This is the major problem with GWT/selectAlternative.  Previously when \
> > > > > > GWT was bytecodes we at least had a chance to get some profile \
> > > > > > information on which way the branch was likely to go but with the \
> > > > > > ricochet frame version we have no knowledge so each side of the if has \
> > > > > > equal probability.  The were no guarantees that the GWT would always be \
> > > > > > used as a fast/slow idiom but in practice it was so we used to get good \
> > > > > > data.  We'll have to find someway to capture profiles for this if we can \
> > > > > > to treat fast/slow in a more aggressive way.
> > > > > selectAlternative has a branch profile.  As long as GWT is being used as \
> > > > > expected (for fast/slow splits), selectAlternative will have a fast/slow \
> > > > > profile, just like the original GWT invokers. 
> > > > > The PROB_FAIR in CallGenerator::for_method_handle_inline could be made \
> > > > > "smarter", by feeding from the control inputs of the Phi; that would be a \
> > > > > good start.
> > > > Well duh on me.  When I wrote that my brain was thinking cmove instruction, \
> > > > not a real If diamond with probability.  I don't think fixing this will \
> > > > improve the inlining in the fast case but it should reduce useless inlining \
> > > > in the slow path.  I've got part of this working. 
> > > > tom
> > > 
> > > But all GWT share the same selectAlternative, so the probability
> > > of the inputs of the Phi is the propability of all GWTs.
> > > I think it's better to artificially mark the fallback as never been 
> > > called instead of relying
> > > on a global shared profile.
> 
> 
> One way to do this on the cheap is to intrinsify selectAlternative in MHW, so that \
> MHW-compiled GWT graphs automatically get fresh profilable copies of the \
> if/then/else.  This doesn't scale to other kinds of MH graphs, of course, but GWT \
> is arguably a fundamental building block that deserves special case to be rendered \
> as if/then/else bytecodes.


I'm not sure I understand how that would help.  When MHW compiles a MH chain we are \
compiling with C2 and we don't do profiling with C2 generated code, AFAIK.  Or did \
you mean something else?

-- Christian


[prev in list] [next in list] [prev in thread] [next in thread]