I've been experimenting with invokedynamic in a compiler for a dynamic
language
that I'm working on, and I've run into a problem that I'm having difficulty
solving.
Let's say I have a class called A (Java syntax used for clarity):
public class A {
}
And another called B, that is a subclass of A:
public class B extends A {
public Value foo;
public Value bar;
}
There will be lots of other subclasses of A as well (let's call them C, D,
E,
etc), some of which will have a field called foo, and some of which won't.
The
class A will never have any fields -- its sole purpose is to be the base
class
of everything else.
I have been able to successfully use a static bootstrap method in B, so
that I
can compile a call to invokedynamic on the imaginary method get_foo() of an
instance of B, and then reroute the call inside B's bootstrap method via
MethodHandles.Lookup.findGetter(), and finally return the current value of
foo.
So far, so good.
However, at the place where I am compiling the invokedynamic instruction, I
have no idea if the target is a B, C, D, or what. All I know is that it
must
be an A.
So what I really want to be able to do (I think) is to use a static
bootstrap
method in A. I want get_foo() to succeed for every invokedynamic call to an
instance of A who's *subclass* really does have a field called foo.
Unfortunately there doesn't seem to be a way to make A do what I want. I
understand why that is -- foo doesn't exist in A, so there is no way to
create
a findGetter() call. But I'm hoping there might be some clever way to do it
anyway. I've tried all kinds of different approaches (making yet another
invokedynamic call from inside A, etc, etc) but I can't come up with
anything
that works.
Any ideas?
By the way, I've figured out how to do this the "old" way, by generating
interfaces for each class that has e.g. a foo field, and casting to that
interface every time I compile a get_foo() invocation. This works, and its
reasonably performant, but using invokedynamic seems like it would be a more
elegant and flexible solution.
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
