What can we improve in JSR292 for Java 9?

[Mark Roos]

John posed two questions on stating points for PICs in jsr292.  The first 
referenced Charleies method handle binder as an
example.  While interesting this tool is aimed at making it easy to 
generate MH chains not at improving performance.
And performance is really what I would like to see.  For this I agree with 
John that perhaps the issue is providing more information
on 'intent' to the JVM.

Thinking a bit about my use of GWTs to create PICs for my Smalltalk 
implementation I believe that we do not need new
constructs if the JVM can optimize the existing ones.  To develop this 
thought I would like to walk through my use
case and explain what I would like to see as optimizations.

I determine which method handle to invoke by comparing an object ref 
contained in an instance var of the object
on top of the stack with one tagging the method handle.  This could be an 
int and a specific slot if that helped. 
Just a note that this is not a 'class' identifier.  its a pointer to the 
head of a linked list of behaviors.  This was shown in the
past to speed up the lookups and add flexibility in inheritance. 

So my first expectation is that the JVM will see that I am doing this and 
reduce it to a memory-memory compare with
pre computed offsets.

So now my four cases
        80% of my call sites are monomorphic.  This should optimize to a 
compare and branch where the branch
        is never taken.  I assume that the processor branch prediction 
will hide this making 80% of my call sites
        free.  Of course I would expect it to be inlined.
 
        15% of them are bi morphic.  This should be the same but with two 
inlined compare/branches with code
        inlined as well.

        4=5% are polymorphic to the extent that less than 10 targets 
exist. This again should be just inlined
        compare/branches.  Perhaps the depth allowed should be settable. 
Overflows would go to a MH on a table
        lookup,  Here the code no longer needs to inline

        A small amount are mega morphic,  usually 100s or more targets. 
Often a list of targets which match the
        number of classes ( heap walking ).  This is a table lookup or a 
long GWT chain but optimizing it is not
        that important to me.  However I do notice a special case here. 
For most of these sites there is only one
        actual code implementation ( or a few).  So if I invert the PIC to 
be one of handling the special cases via
        a chain of GWTs and make the fallback the common case I can turn a 
megamorphic site into a monomorphic one.
        This would want the fallback to be fast as it would be the most 
common.

So to make me happy just a good compiler on top of today's constructs. And 
maybe a knob or two.

Cool things?
        Reflection on the site would be nice.  Along with path counters. 
Then I could rebuild the call sites based on profiling.
        Replacing MH targets would allow specialization perhaps or maybe 
just sorting between the GWT part and
        the table lookup.  Cool but I am not sure I would need them.

regards
mark


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