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 ?
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 ?



mlvm-dev mailing list

Reply via email to