A simple PIC api

[Mark Roos]

Thanks Rémi,  I was looking for a paper like that.  Not for multimethods 
but for a way to 
improve code reuse across a hierarchy.  Will savor it later with a fine 
pinot :)

What I was thinking about for multi methods was a simpler tree like 
approach.
http://dl.acm.org/citation.cfm?id=28732

In my proposed pic the test method handle examines the arguments and 
returns a behavior
token.  By using a custom test for that call site I believe that the 
overhead will be acceptable.
But I don't want to recalculate it N times for N guards. Of course I will 
be able to implement
this with just the current MH support.

        If you want efficiency, you still have the issue that to be 
efficient you need to inline the code of all method 
        handles inside the code of the caller and you can not do that if 
there 
        are too many possible implementations i.e. if the callsite is 
megamorphic.

My thoughts around megamorphic sites is to note that they very often have 
only a few implementations ( like Object at: ).
I was thinking about inverting the test logic when a site gets too large 
and I know there are less than N implementations.
The paper you referenced may help here.

        Currently, if a callsite is monomorphic and you have a way to 
prove it upfront, you can use a switchpoint

Agree,  but all sites can be assumed to be such until proven otherwise 
(80%)   It would be nice if a single GWT would be no more
expensive.

        If you have a polymorphic callsite, guards are your savior, it's 
work pretty well until you 
        have too many guards (it's a linear scan after all).

Yes this is my current model

        If you have a megamorphic callsite, you can use an exactInvoker + 
a fold, but you basically give up on inlining.

This may be a good fallback

        The other solution is to ask the VM to do a tableswitch on the 
method handle value (or on an int that represents 
        the method handle value). We have no specific method handle for 
this case so you will have to generate bytecode.

I was going to try this ( I already do my own bytecodes ) so thanks for 
the reinforcement.  My roadblock here is how to
convert the 20K behaviors to the int to use for the table switch, it would 
be very sparse.  I think due to the rarity of sites
with more than 10 receivers that I may just take the hit of letting them 
be rebuilt when they pass some size.  This follows
an observation that often sites which are megamorphic in the long term are 
not over shorter time spans.

        So let me try to understand what you want, you want a combiner 
that will do an inlining cache or a polymorphic inlining 
        cache with guards if there are few possible targets, this combiner 
will be able re-arrange the guard checks because the user 
        guarantee that the check do no side effect. And if there are too 
many guards, the combiner will use a tableswitch to still try 
        to inline targets at callsite until there are so many possible 
targets that the cominer will in that case only use an 
        exactInvoker + a fold.

        how far am I from what you are thinking ?

I think I would be happy with that. But I would also be happy with a 
simpler building block which satisfies a subset of
these requirements with blazing speed.

My minimum is a construct which 
        manages a short ( 1 to ?? ) inline set of GWTs and turns them into 
compare/branch instructions.

        takes a method handle which when passed the stack args returns an 
integer to use for the selection
        so only one execution of the test method

        if there is a miss or overflow passes to the fallback mh for a 
lookup

        can optionally insert the new mh into the front of the managed set 
or just execute it and discard it 
        ( handles megamorphic  or a table lookup)  based on the reply from 
the fallback ( a tuple  of int,mh)

        all paths are assumed fast

        always inlined

        the optimizer doing the right thing


thanks again
mark




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20150312/df927c3d/attachment.html>