Spread arguments would have been nice to have. Another related messy argument issue, which took me a while to deal with, was handling the receiver (this) object being on top of the stack. Since my GWT test needs to act on the receiver I ended up caching an airity specific drop MH. While is works is does seem to be a complicated solution. I was expecting something like a 'pop' but never found it. Of course if I had a pop then a push would let one do top of stack replacements.
As for PICs. The more I think about them to messier they look from a generic api standpoint. It does depend on the goal. If its ease of use then its probably not as hard as if one wants to fine tune the optimization. For me the simplest PIC is simply a test target extractor MH, a cache of choices and a fallback MH to handle cache misses. The simplest UI to this is to let the jvm make its own decisions on implementation. The fallback MH would need the callsite bound to it to pass lookup values. Taking the fallback path should also add to the cache and execute the found MH. By putting all of the operations in one entity some of the hard to understand operations like extending the GWT chain and executing the found method are avoided. Internally this PIC would do some amount of compare branches, if those fail a table lookup and if that fails call the fallback. I seem to recall a paper in the past that indicated 2 compare branches was the big gain with no help after 5. Of course the optimizer would be monitoring the MHs used and move them between the table and the compare/branches. This approach would require quite a bit of work on the jvm side. Perhaps a simpler version would just be a mult GWT (mgwt). Is this case we would get a method handle which took a test target extractor MH, a table of tuples ( test target, MH) and a fallback. It would just extract the test target, compare the N tuples and fallback on failure. The only added complexity is how to update the table of tuples dynamically by the fallback. Perhaps we should redefine how fallback works to return a new MH to add to the table. This MH is added ( replacing the least used current value) and the MH executed. This would also remove the need to provide and update the table. So the constructor api would be (test extractor MH, fallback MH, callsite). This api would be way simpler than the current one. mark
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
