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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
