Two proposals for simple PIC support

[Mark Roos]

Summary,  I would like to consider a projection based PIC along with a 
highly
optimized GWT based one.

After a short discussion,  some reading and a reexamination of my use 
model I
feel like there are two designs for a PIC api which I would like to hear 
suggestions
on.  I am planning a comparison so any suggestions are welcome.
The two would differ in how they look up the cached method handles from 
the
on stack arguments, one would be based on pattern matching and the other
on a projection to an integer.  My use model shows that call sites rarely 
have more
than 10 different targets ( Truffle uses 8 ) so I am not concerned about 
mega
morphic being efficient.

A pattern matching PIC could be modeled as a chain of GWTs ( guard with 
test).
The arguments are passed to each test which decides if its implementation 
is 
a match.  It there is no match a new GWT is prepended based on an argument
dependent look up.   This style is easy to do with the existing method 
handle
library.  I use it and it works fine for a single receiver dispatch and I 
see it 
working for multi methods as well.   My only concern has been the ability 
of the
JIT to optimize this well without knowing its a PIC.  So perhaps a special 

call site or annotation would be all this needs.

The projection version would use a projection method handle to convert the 
stack
arguments to a integer projection.  The cache would use this integer as 
its key. The
api could look something like
        MethodHandle createProjectionPic(MethodHandle projection, 
MethodHandle lookup)
the projection
        long projectFoo(Object.... args)  I use a long as I think I will 
want a 64 bit vector
the lookup
        MethodHandle lookupFoo(Object.... args)  the returned MH is added 
to the cache

Pretty much the same as today's GWT.

I am not sure if I can implement this well using the current method 
handles api 
( suggestions welcome)  but the main effort here is if I can determine an 
effective projection 
to use.  I can see it as easy for the single receiver based dispatch (I 
will just add the 
projection as a field) but what I want to see if I can use this to take 
advantage of the 
observation that there are often only a few implementations of a method 
even though 
there are many inheritors.  If this is true then most of my megamorphic 
sites will become
polymorphic.

This does not solve all of my observed megamorphic sites but probably 99% 
of them.

regards
mark







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