On why I am looking at projections for behavior determination.
In my case I use an object reference in the receiver to determine the method to execute. One
could say that this is a projection from the class to an address which is an integer. So in this
case computing the projection is the same as testing for a class match. However I see this as
limiting. The address could be 64 bits but I only have 5000 classes so many of the bits are
not used. My theory is that if I replace the object reference with a long ( call it a bit vector )
and then compute the mapping of the class behavior to some set of bits then I can compute
the target behavior by logical operations on the projections for each arg. Since these would
all be ops on longs ( or ints maybe) they would be fast to perform.
So my current efforts at analysis is to handle the following use cases.
For call sites where the number of receivers it less than some small number I plan to just
use the standard compare the class behavior approach. This could be faster if the item
compared is a integer vs a reference.
For cases where there are only a few implementations of a method but many receivers. I plan
to use some logical combination of bits so select the method.
For cases where the class of an argument plus the receiver is used. ( specialization ). Some
bits again.
For the case of many methods and many receivers. Not sure about this yet. This is usually
some method like 'name' which returns a constant. Perhaps moving the constant to an instance
var would trade memory size for performance.
I also believe that I can determine these projections via a static analysis plus some profiling.
One question will be how much does the profiling help.
It may be true that a tree structured test is just as effective as manipulations of a bit vector. It
may also be true that the cases which could benefit from projections do not impact the apps
performance. Makes for a nice analysis.
In any case I agree with you on performance being the goal. Probably a optimal GWT chain
will in the end be all that is needed.
regards
mark
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
