Updates on Da Vinci Machine Work

[Patrick Wright]

Hi all,

For those not following the Multi-Language Virtual Machine ("DaVinci
Machine") mailing list [1], there is a new thread [2] with updates on
the status of various sub-projects.

John Rose, invoke dynamic & etc:
http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000321.html

Rémi Forax, invoke dynamic backport:
http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000323.html

Tobias Ivarsson, interface injection:
http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000327.html

Arnold Schwaighofer, tail calls:
http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000331.html

Regards,
Patrick

1: http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
2: http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000321.html

[Charles Oliver Nutter]

Patrick Wright wrote:
> Hi all,
>
> For those not following the Multi-Language Virtual Machine ("DaVinci
> Machine") mailing list [1], there is a new thread [2] with updates on
> the status of various sub-projects.
>
> John Rose, invoke dynamic & etc:
> http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000321.html
>
> Rémi Forax, invoke dynamic backport:
> http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000323.html
>
> Tobias Ivarsson, interface injection:
> http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000327.html
>
> Arnold Schwaighofer, tail calls:
> http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000331.html

All super-exciting stuff, especially the fact that Arnold claims that
tail calls are almost finished. We're going to have some wonderful toys
soon.

- Charlie

[Patrick Wright]

> All super-exciting stuff, especially the fact that Arnold claims that
> tail calls are almost finished. We're going to have some wonderful toys
> soon.

Yup. IMO it seems like an important near-term goal is to ensure that
the patch/build loop for the relevant bits is smooth enough that every
lang implementor has something stable to work against. I imagine at
least a build server, if not some kind of VM image, would be a great
nice-to-have. That will help set up a feedback loop as people roll
these features into their compilers.

Patrick

[John Rose]

Thanks for the cross-post, Patrick. One more item is NetBeans
support, which maybe someone on this list can help with:
http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/
000336.html

On Jan 21, 2009, at 4:57 AM, Patrick Wright wrote:
> For those not following the Multi-Language Virtual Machine ("DaVinci
> Machine") mailing list [1], there is a new thread [2] with updates on
> the status of various sub-projects.

I think once we have basic support in Java for method handles,
invokedynamic, and exotic identifiers, we can use Java as a system
language to write language runtime support in many cases where we'd
otherwise have to roll the bytecodes by hand.

(Tailcalls are another important feature for runtimes; clearly
runtime systems want to use tailcalls to delegate bits of work
between modules without adding to the control stack. That will come
pretty soon, thanks to Arnold.)

As Attila said at the Summit in September, this new stuff probably
has strong implications on the design of a MOP. The main example is
using method handles to express units of procedural semantics; the
MOP's job of handing out such units is streamlined if those units can
be directly invoked (as in invokevirtual or invokedynamic) by the MOP
client, instead of called through a reflective veil of boxed
varargs. Getting this working requires that the client code which
uses the MOP must be able to emit method handle calls. If the Java
language supports these things, then the MOP clients can be written
using javac not just ASM, which makes a JSR 292-based MOP viable.

-- John

[John Rose]

On Jan 21, 2009, at 11:50 AM, Patrick Wright wrote:

That will help set up a feedback loop as people roll

these features into their compilers.

Yes, it's frustrating to find new build bugs every time new code goes into the repo.

The method handles stuff will be going into the JDK 7 repos, which means the standard JDK 7 RE builds will include the stuff.  That will make things *much* easier, though it won't provide rapid access to recent mlvm fixes.

-- John

[Attila Szegedi]

Indeed. I did actually start toying with an implementing of this after
the summit, but I quickly run into the problem of missing
implementations of important intrinsic method handles - I would have
needed guardWithTest, insertArgument, and collectArguments for a
monomorphic cache, a collectArguments for varargs, and so on. All I
had to work with was Rémi's backport, which doesn't (yet) implement
these, so I shelved it for the time being, but the overall direction
seems to be valid.

On a sidenote, I would also be a happy user of a prebuilt MLVM binary
(for Mac OS X, no less; alternatively, I might really look into
installing OpenSolaris into VMWare).

Attila.

[John Rose]

Working on a pre-build solution for mlvm..

Since I'm developing on mac/vmware/solaris, as soon as we get our
Openjdk mac story straight, the mlvm stuff should follow as a
corollary.(Actually it's sparc that needs love right now on mlvm.)

-- John (on my iPhone)