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