Am 12.03.2015 19:37, schrieb Mark Roos:
Jochen
The comment on the test part of the pic is interesting. Since I am
looking at multimethods
I would like to have a better understanding of how you decide which
code to dispatch at a site.
We currently have no PIC in Groovy. The naive implementation would be
using the guards I use to check for the validity of my current method
selection. But that means several guards to check the receiver and each
argument as well as a switchpoint to ensure the validity of the meta
class. So for a N argument call we have up-to N+1 guards. The guard will
ensure the value is of the expected class and not null. Since I
transport static information if available I can skip the guard for
primitives. I could in theory skip the class check for final classes,
but since null would be still a legal value and since it would
potentially change the selected method, I would still have a guard. What
I could do further, which I haven't done yet, is to check the overloads
of the method. If there are none, I need only one guard for the
receiver. And depending on the signatures I could also omit single
guards. Problem is that the internal structures we currently have, have
not been written to make this happen efficiently, which is why I did not
go further yet.
My pic suggestion assumes that one test method is applied to the
arguments and its result
used to select the code to execute. This may be too limiting to be the
general case.
But you made me think... considering a guard like this:
boolean testArguments(Object[] args, Class[] types) {
for (int i=0; i<types.length; i++) {
if (types[i]!=null) {
if (args[i]==null || args[i].getClass()!=types[i]) return false;
} else {
if (args[i]!=null) return false;
}
return true;
}
plus some dropping of arguments to skip parts I don't want to guard, I
could indeed go with one test handle. For null and class. The question
though is how the performance of this would be. (Haven't tested it)
The way I reason about a pic is that it is presented the current stack
args and if it does
not see a match the stack and the site are passed to the fallback. The
fallback has
two responsibilities, to find the code for the current args and to
generate a test which
when applied to args in the future will dispatch the same code.
Yes, that was the same in my suggestion
I see
this test as
a pattern match against some facet of the args. Since I use a chain of
GWTs each guard
can have a different test/match. I am looking at some form of bit
vector for the facets and the
pattern to match ( as in the paper Rémi suggested) so I don't have to
have a complex tree
like test.
Yes, a tree of tests should be avoided, I totally agree. Same for the
code I have shown above probably.
So far I have avoided using projections since I am not sure about how to
do this. Basically I am missing a way to project a Class to an usable
int. I guess if I wanted to I could use the hashcode sum as a
potentially quick first test and then continue from there.
Perhaps my original thought of just declaring the site to be a pic and
letting the jvm do its
best optimizing the target will be the best.
needs testing I guess
bye Jochen
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
