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