indy and tailc

John Rose John.Rose at Sun.COM
Tue Jan 26 14:01:47 PST 2010


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



More information about the mlvm-dev mailing list