New could would mean adding a {MethodHandle, ConstantPoolData}
tuple to a particular callsite?s representation.
Now if we could add a item for the object reference used for the
comparison in the test part of a GWT we would have a structure which could
be used
in a PIC (polymorphic inline cache) implementation.
A PIC then would be this collection, a test method handle ( used to
extract the comparison value
from an object on the stack) , a fall back method handle, perhaps a
overflow handle ( if the inlining is exceeded),
and some attributes to inform the compiler of how to optimize ( e.g inline
depth of the guards).
Reflection and branch counters would be nice if we are expected to
optimize externally ( order and size of inlining ).
An interesting optimization is that often many objects share the same
code, sometimes there is only one
implementation for all objects. This essentially turns most megamorphic
sites into monomorphic. Of course
with a dynamic language its hard to guarantee this. But one could have an
inverse PIC. One where its built
with markers for the unique implementations and does a fast fallback to
the common. Perhaps the solution
to this is Panama and a local JIT, so maybe a callsite which wrappers an
intrinsic like piece of could would do it.
It would be nice if this level of detail was hidden by the jvm.
As an aside the fast path slow path nomenclature is bothersome as most of
the time they are all fast. Only the
fallback which does a look up is slow.
mark
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
