A simple PIC api

[Remi Forax]

On 03/11/2015 11:12 PM, Mark Roos wrote:
> From Jochen
>
> Do I also understand right, that your test for checking if the current
> target is still valid is limited to only the receiver?
>
> Well yes and no.  In my case the test examines all of the arguments on 
> the stack and computes
> an 'behavior' reference.  This reference is the head of a linked list 
> of method dictionaries which
> the fallback searches to locate the code for this callsite and that 
> behavior.  The yes part is that
> in my Smalltalk the behavior is stored in a field of the object on the 
> top of the stack.  This happens
> to be the receiver.
>
> For the proposed api the test can examine the entire stack and 
> callsite to determine the dispatch.
> I do plan to support multi methods which could be an expensive test. 
>  I just wanted to do it once
> regardless of the number of guards.
>
>         I also do special
>        things to not add guards if I can, since each guard costs... 
> though the
>        information I use there is static so far
>
> I would expect in a perfect world for the guards to be cheap if the 
> jvm knew the were part of
> a pic.

Do you mean you plan to use something like this ?
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.37.594&rep=rep1&type=pdf
the result of the dispatch algorithm will be either a method handle 
corresponding to the implementation to call.

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.

Currently, if a callsite is monomorphic and you have a way to prove it 
upfront, you can use a SwitchPoint with no guard at all (think something 
like there is only one class that implement this interface).
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).
If you have a megamorphic callsite, you can use an exactInvoker + a 
fold, but you basically give up on inlining.
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.

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.

Currently, this can not be implemented easily for two reasons,
- you may not want profile counters that profile the different branches 
to be included in the JITed code, so you need a way to specify a special 
method handle that will execute a method handle in the interpreter but 
that will not appear in JITed code.
- you want the VM to be able to generate a tableswitch which is not 
something the VM is able to do now.

how far am I from what you are thinking ?

>
> regards
> mark

cheers,
Rémi

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