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