On Jan 26, 2010, at 5:02 AM, Raffaello Giulietti wrote:
Good questions; thanks Raffaello.
> What is the current status of "tailcalls meet invokedynamic"? I mean,
> not the interesting entry in John's blog but the status in the
> implementation?
It's not yet started. It requires some pretty interesting work with stack
frames. MH adapters internally perform tail calls currently, and both adapters
and security boundary markers could benefit from stack trace "compression"
(frame reuse). I think there's some common infrastructure to invent here. If
someone out there wants to dive in, please do. (Read some of the Linz Hotspot
theses first.)
> And what about
> * AnonymousClasses
The POC is in there. Integration with method handles requires interpreter &
compiler work.
> * ImmediateWrappers
I haven't seen any mlvm work for this one. Requires large-scale refactoring,
as did compressed oops.
> * TupleSignatures
This one is long overdue. It's worth prototyping now just because of the
possible connection with function types. Nobody at Sun/Oracle is working on
it, as far as I know.
(The data-structure implications entail I call "mixed arrays" or Maxine calls
"hybrids". They would be an array of tuples, possibly with a header containing
more instance variables. More on that later.)
For starters, someone should do a signature-annotation convention that will
support both tuples and non-erased function types. That wouldn't be hard.
Maybe something like {(Ljava/lang/Tuple;)II} for Tuple<int,int> or
{Ljava/dyn/MethodHandle;(IIV)} for a function type. The rough idea is that the
curly brackets are erased, and within them everything inside round brackets is
also erased, when stacking arguments and return values in the verifier,
interpreter, or compiler. But for linking and distinguishing overloads, all
the characters are significant. The trickiest part is multiple-value returns,
but that doesn't have to be done first.
The ongoing success of the mlvm project will depend partly on how much the
community "votes with code". Tail calls, continuations, and the JSR 292
backport are outstanding successes for community-contributed code. Shall we do
some more? (Just wondering about it today. No special reason... :-)
-- John
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
