What can we improve in JSR292 for Java 9?

[Mark Roos]

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20150307/9a16abd6/attachment-0001.html>