Inlining heuristic trouble

[Mark Roos]

Not that I am the expert here but...

In the Smalltalk we are porting the typical call site supports only a few 
actual classes.  So the method look up ( which is based on the object 
class )
only chooses from a small set ( mostly a single choice).  This set is 
built up during run time by watching the classes which appear at the site. 
 

So the basic operation is
        test if the class coming in is one we have seen before
                if yes then jump to the method
                if not then do a lookup and compile of the new method ( 
this is the slow path)
                put this into the local method cache by placing a new GWT 
at the front of the chain
                execute the new method.

Since there is only a few choices the guard with test is a very quick way 
to test the class ( fast path )
We end up with a chain of tests which ripple through the known classes and 
then end with the real slow lookup of the new class.
For a small amount of classes to check this is fast in 8086 code.

So we do not have a path that can be assumed to be not taken (except the 
last in the chain).

Perhaps in the JVM this is a poor choice for implementation of a small 
polymorphic inline cache.  Here I defer to the real experts

regards
 mark





From:
Tom Rodriguez <tom.rodriguez at oracle.com>
To:
Da Vinci Machine Project <mlvm-dev at openjdk.java.net>
Date:
06/20/2011 12:18 PM
Subject:
Re: Inlining heuristic trouble
Sent by:
mlvm-dev-bounces at openjdk.java.net




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.

Are you suggesting that MethodHandles.guardWithTest should always assume 
that the second choice is effectively never called?  That seems like a 
strong assumption.  It unfortunate that the method handles interface 
doesn't give better hinting for something like this.

Can someone explain the idiom being used here a little more?  It seems 
like selectAlternative is being used to build a caching call site but I 
would have expected that to be a more first class object, like a CallSite 
subclass with a guard and fallback.

tom

> 
> Also, the fallback will be called a few times (usually at least once) 
> before the target
> of a callsite becomes stable so a global profile will be artificially 
> pollutedp
> by the initialization phases of all GWTs.
> 
> Another way to solve the problem is to generate the code twice as the 
> tiered compilation does.
> The first generation will include MDOs that will be used by the second 
> generation.
> 
> Rémi
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

_______________________________________________
mlvm-dev mailing list
mlvm-dev at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110620/787a6009/attachment.html