From Christian.Thalinger at Sun.COM  Mon Mar  1 03:06:01 2010
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Mon, 01 Mar 2010 11:06:01 +0000
Subject: hg: mlvm/mlvm/hotspot: indy-sparc-6829193: Initial SPARC interpreter
	support.
Message-ID: <20100301110605.C8D3241D4D@hg.openjdk.java.net>

Changeset: dd0f39afbe36
Author:    twisti
Date:      2010-03-01 03:04 -0800
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/dd0f39afbe36

indy-sparc-6829193: Initial SPARC interpreter support.

+ indy-sparc-6829193.patch
- indy-sparc.patch
! series


From John.Rose at Sun.COM  Fri Mar  5 22:51:16 2010
From: John.Rose at Sun.COM (John Rose)
Date: Fri, 05 Mar 2010 22:51:16 -0800
Subject: Invokedynamic and Multiple Dispatch
In-Reply-To: <4166759f1002281548o38084816t837d7eb0ee989a71@mail.gmail.com>
References: <4166759f1002281548o38084816t837d7eb0ee989a71@mail.gmail.com>
Message-ID: <8316E9C2-CDE1-4F25-8DB0-E5A55185727C@sun.com>

On Feb 28, 2010, at 3:48 PM, Larry Chester wrote:

> So I've been playing around with invokedynamic (with build 84),
> however I've stumbled on something I find quite strange!
> 
> Consider two objects a and b that both reference a String. a is
> declared as a String but b is only an Object. When I dynamically
> invoke with either a or b as an argument I would expect the MethodType
> passed to the bootstrap method to be identical.
> 
> String a = "hello";
> Object b = a;
> InvokeDynamic.<void>foo(a);
> InvokeDynamic.<void>foo(b);
> 
> However, when called with a, the MethodType is (java.lang.String)void;
> but with b, it is (java.lang.Object)void.

How could it be otherwise?  The static type of b is Object, while the static type of a is String.  If they happen to have the same dynamic type, that has nothing to do with the semantics of bytecoded call sites.

> I've dug around all over the place but can't find anything that
> confirms what the behaviour should be in this case. I was hoping
> invokedynamic could be used for multiple dispatch but that doesn't
> appear possible.
> 
> I'm interested what the intended functionality is in this case. Is
> that a bug or intended?

Totally intended.  How does this hinder multiple dispatch?  In fact, the extra information about static type, which is distinct from the dynamic types of the actual arguments, gives you the information you need to accurately model Java's static overload resolution rules.

If you are modeling some other form of multiple dispatch (there are many ways to do it) you can just ignore the static types and convert everything to object.  Note that MethodHandles.convertArguments gives you a way to adapt your own target method (which might be (Object)->Object) to the required call site target (which might be (String)->void).  The JVM will insert any casts needed to make up the type differences.

-- John

From larry.chester at googlemail.com  Sat Mar  6 17:21:35 2010
From: larry.chester at googlemail.com (Larry Chester)
Date: Sun, 7 Mar 2010 01:21:35 +0000
Subject: Invokedynamic and Multiple Dispatch
In-Reply-To: <4166759f1002281548o38084816t837d7eb0ee989a71@mail.gmail.com>
References: <4166759f1002281548o38084816t837d7eb0ee989a71@mail.gmail.com>
Message-ID: <4166759f1003061721h771027f5haae1311810f6b1d2@mail.gmail.com>

Thanks for your reply!

My aim is to dispatch based on the dynamic type of the Object as described in:

http://en.wikipedia.org/wiki/Multiple_dispatch

Currently my implementation revolves around building a HashMap that
maps a dynamic type to a MethodHandle and invoking that:

HashMap<Class, MethodHandle> lookup = new HashMap();

MethodType type = MethodType.methodType(void.class, String.class);
MethodHandle func = MethodHandles.lookup().findStatic(Main.class, "foo", type);
lookup.put(String.class, func);

Then to invoke on an Object x:

lookup.get(x.getClass()).invokeGeneric(x);

This is quite slow though (although I believe the bottleneck is in the
invokeGeneric call).

From John.Rose at Sun.COM  Sat Mar  6 17:59:04 2010
From: John.Rose at Sun.COM (John Rose)
Date: Sat, 06 Mar 2010 17:59:04 -0800
Subject: Invokedynamic and Multiple Dispatch
In-Reply-To: <4166759f1003061721h771027f5haae1311810f6b1d2@mail.gmail.com>
References: <4166759f1002281548o38084816t837d7eb0ee989a71@mail.gmail.com>
	<4166759f1003061721h771027f5haae1311810f6b1d2@mail.gmail.com>
Message-ID: <B70427A6-5BE4-4C17-97CD-E2488FCEF143@sun.com>

On Mar 6, 2010, at 5:21 PM, Larry Chester wrote:

> Then to invoke on an Object x:
> 
> lookup.get(x.getClass()).invokeGeneric(x);
> 
> This is quite slow though (although I believe the bottleneck is in the
> invokeGeneric call).

I can certainly believe that:  invokeGeneric is not fully implemented yet.

Try this instead:
	lookup.put(String.class, func.asType(func.type().generic()));

Then you can call any handler with a fast exact call:
	lookup.get(x.getClass()).invoke(x);  // x must be an Object

-- John

P.S. The name MH.invoke will be changing to MH.invokeExact, to emphasize the difference from invokeGeneric.

From eller.helmut at gmail.com  Sun Mar  7 00:04:30 2010
From: eller.helmut at gmail.com (Helmut Eller)
Date: Sun, 07 Mar 2010 09:04:30 +0100
Subject: Nullpointers not checked
Message-ID: <m2hbospng1.fsf@gmail.com>

A non-text attachment was scrubbed...
Name: Foo.java
Type: text/x-java
Size: 1013 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100307/38cb6f5b/attachment.bin 

From headius at headius.com  Sun Mar  7 06:01:19 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Sun, 7 Mar 2010 08:01:19 -0600
Subject: Recent build for OS X (Snow Leopard, if it matters)?
Message-ID: <f04d2211003070601q724e0128jb83726905de1ed16@mail.gmail.com>

Hey, I need to get back into MLVM and thought I might be able to
piggy-back off someone else's build. Anyone got an OS X build of
recent MLVM stuff?

- Charlie

From stephen.bannasch at deanbrook.org  Sun Mar  7 16:10:58 2010
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Sun, 7 Mar 2010 19:10:58 -0500
Subject: Recent build for OS X (Snow Leopard, if it matters)?
In-Reply-To: <f04d2211003070601q724e0128jb83726905de1ed16@mail.gmail.com>
References: <f04d2211003070601q724e0128jb83726905de1ed16@mail.gmail.com>
Message-ID: <p06240800c7b9ef91e77b@[192.168.1.106]>

At 8:01 AM -0600 3/7/10, Charles Oliver Nutter wrote:
>Hey, I need to get back into MLVM and thought I might be able to
>piggy-back off someone else's build. Anyone got an OS X build of
>recent MLVM stuff?

Here's a build from today on 10.5.8, should work fine on Snow Leopard:

http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-2010_03_07.tar.gz (54 MB)

Here's the script I use to build mlvm: http://gist.github.com/243072

From Christian.Thalinger at Sun.COM  Mon Mar  8 01:30:38 2010
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Mon, 08 Mar 2010 10:30:38 +0100
Subject: Nullpointers not checked
In-Reply-To: <m2hbospng1.fsf@gmail.com>
References: <m2hbospng1.fsf@gmail.com>
Message-ID: <1268040638.27679.12.camel@macbook>

On Sun, 2010-03-07 at 09:04 +0100, Helmut Eller wrote:
> The attached program crashes with this message:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (sharedRuntime.cpp:586), pid=4116, tid=3072834448
> #  Error: guarantee(cb->is_adapter_blob(),"exception happened outside interpreter, nmethods and vtable stubs (1)")
> #
> # JRE version: 7.0
> # Java VM: OpenJDK Server VM (17.0-b05 interpreted mode linux-x86 )
> # An error report file with more information is saved as:
> # /tmp/hs_err_pid4116.log

Yes, that is a bug.  The null-pointer check is there but the implicit
null-pointer exception in the MethodHandle adapter is not recognized.

I will fix that as part of 6932091.

Thanks for finding this!

-- Christian


From headius at headius.com  Mon Mar  8 06:02:06 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Mon, 8 Mar 2010 08:02:06 -0600
Subject: Recent build for OS X (Snow Leopard, if it matters)?
In-Reply-To: <p06240800c7b9ef91e77b@192.168.1.106>
References: <f04d2211003070601q724e0128jb83726905de1ed16@mail.gmail.com> 
	<p06240800c7b9ef91e77b@192.168.1.106>
Message-ID: <f04d2211003080602u7d9bb320o575da716f1ae3491@mail.gmail.com>

Thanks and Thanks, Stephen :)

On Sun, Mar 7, 2010 at 6:10 PM, Stephen Bannasch
<stephen.bannasch at deanbrook.org> wrote:
> At 8:01 AM -0600 3/7/10, Charles Oliver Nutter wrote:
>>Hey, I need to get back into MLVM and thought I might be able to
>>piggy-back off someone else's build. Anyone got an OS X build of
>>recent MLVM stuff?
>
> Here's a build from today on 10.5.8, should work fine on Snow Leopard:
>
> http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-2010_03_07.tar.gz (54 MB)
>
> Here's the script I use to build mlvm: http://gist.github.com/243072
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>

From Christian.Thalinger at Sun.COM  Mon Mar  8 06:57:01 2010
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Mon, 08 Mar 2010 14:57:01 +0000
Subject: hg: mlvm/mlvm/jdk: meth.test.patch: Some changes and enhancements to
	MethodHandlesTest.
Message-ID: <20100308145702.CA5A7442DE@hg.openjdk.java.net>

Changeset: 9a2955e2eb03
Author:    twisti
Date:      2010-03-08 15:53 +0100
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/9a2955e2eb03

meth.test.patch: Some changes and enhancements to MethodHandlesTest.

+ meth.test.patch
! series


From Christian.Thalinger at Sun.COM  Mon Mar  8 07:28:55 2010
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Mon, 08 Mar 2010 15:28:55 +0000
Subject: hg: mlvm/mlvm/jdk: indy.tests.patch: Enable tests for amd64, sparc,
	and sparcv9.
Message-ID: <20100308152856.05226442E7@hg.openjdk.java.net>

Changeset: 8a510a72285c
Author:    twisti
Date:      2010-03-08 16:28 +0100
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/8a510a72285c

indy.tests.patch: Enable tests for amd64, sparc, and sparcv9.

! indy.tests.patch


From lukas.stadler at jku.at  Tue Mar  9 13:12:56 2010
From: lukas.stadler at jku.at (lukas.stadler at jku.at)
Date: Tue, 09 Mar 2010 21:12:56 +0000
Subject: hg: mlvm/mlvm/hotspot: new efficient coroutine implementation
Message-ID: <20100309211257.24EA4444BF@hg.openjdk.java.net>

Changeset: 97cd3db5617f
Author:    lstadler
Date:      2010-03-09 22:10 +0100
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/97cd3db5617f

new efficient coroutine implementation

+ coro.patch
! series


From lukas.stadler at jku.at  Tue Mar  9 13:28:38 2010
From: lukas.stadler at jku.at (lukas.stadler at jku.at)
Date: Tue, 09 Mar 2010 21:28:38 +0000
Subject: hg: mlvm/mlvm/jdk: new efficient coroutine implementation
Message-ID: <20100309212839.19BAE444C3@hg.openjdk.java.net>

Changeset: 12a82472c650
Author:    lstadler
Date:      2010-03-09 22:27 +0100
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/12a82472c650

new efficient coroutine implementation

+ coro.patch
! series


From lukas.stadler at jku.at  Wed Mar 10 08:04:31 2010
From: lukas.stadler at jku.at (Lukas Stadler)
Date: Wed, 10 Mar 2010 17:04:31 +0100
Subject: coroutines
Message-ID: <4B97C30F.5060200@jku.at>

Hi everybody!

As you've probably seen I've pushed a new coroutine implementation into 
the repository.
I've posted a few examples and precompiled binaries on my blog:
http://classparser.blogspot.com/2010/03/coroutines-for-java-status-update.html
Maybe someone wants to give it a try? :-)

cheers,
  Lukas

From headius at headius.com  Wed Mar 10 08:33:06 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Wed, 10 Mar 2010 10:33:06 -0600
Subject: coroutines
In-Reply-To: <4B97C30F.5060200@jku.at>
References: <4B97C30F.5060200@jku.at>
Message-ID: <f04d2211003100833s62d2e087web086883fcddbd4f@mail.gmail.com>

I'm planning on spending a bunch of time next week on MLVM, especially
invokedynamic updates for JRuby and trying out coroutines and tail
calls. So I'll let you know what I see :)

On Wed, Mar 10, 2010 at 10:04 AM, Lukas Stadler <lukas.stadler at jku.at> wrote:
> Hi everybody!
>
> As you've probably seen I've pushed a new coroutine implementation into
> the repository.
> I've posted a few examples and precompiled binaries on my blog:
> http://classparser.blogspot.com/2010/03/coroutines-for-java-status-update.html
> Maybe someone wants to give it a try? :-)
>
> cheers,
> ?Lukas
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>

From Christian.Thalinger at Sun.COM  Thu Mar 11 03:58:39 2010
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Thu, 11 Mar 2010 12:58:39 +0100
Subject: coroutines
In-Reply-To: <4B97C30F.5060200@jku.at>
References: <4B97C30F.5060200@jku.at>
Message-ID: <1268308719.2124.7.camel@macbook>

On Wed, 2010-03-10 at 17:04 +0100, Lukas Stadler wrote:
> Hi everybody!
> 
> As you've probably seen I've pushed a new coroutine implementation into 
> the repository.

I'm just rebasing the mlvm patches to the latest code drop and HotSpot's
coro.patch does not apply cleanly on top of the other patches (I think
it's callcc.patch).  Is that intentional?  Should coro only be applied
without callcc?

-- Christian


From Christian.Thalinger at Sun.COM  Thu Mar 11 04:06:10 2010
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Thu, 11 Mar 2010 12:06:10 +0000
Subject: hg: mlvm/mlvm/hotspot: Rebased to jdk7-b85.
Message-ID: <20100311120611.08D44446F4@hg.openjdk.java.net>

Changeset: 5211c0a2aff0
Author:    twisti
Date:      2010-03-11 13:04 +0100
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/5211c0a2aff0

Rebased to jdk7-b85.

! indy-c1-x86-6919934.patch
! series


From Christian.Thalinger at Sun.COM  Thu Mar 11 04:06:25 2010
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Thu, 11 Mar 2010 12:06:25 +0000
Subject: hg: mlvm/mlvm/jdk: Rebased to jdk7-b85.
Message-ID: <20100311120625.C193D446F5@hg.openjdk.java.net>

Changeset: f93f23bb3f1e
Author:    twisti
Date:      2010-03-11 13:04 +0100
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/f93f23bb3f1e

Rebased to jdk7-b85.

! series


From Christian.Thalinger at Sun.COM  Thu Mar 11 04:06:35 2010
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Thu, 11 Mar 2010 12:06:35 +0000
Subject: hg: mlvm/mlvm/langtools: Rebased to jdk7-b85.
Message-ID: <20100311120635.7D1C6446F6@hg.openjdk.java.net>

Changeset: 4aec48af19fb
Author:    twisti
Date:      2010-03-11 13:04 +0100
URL:       http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/4aec48af19fb

Rebased to jdk7-b85.

! series


From lukas.stadler at jku.at  Thu Mar 11 07:03:24 2010
From: lukas.stadler at jku.at (Lukas Stadler)
Date: Thu, 11 Mar 2010 16:03:24 +0100
Subject: coroutines
In-Reply-To: <1268308719.2124.7.camel@macbook>
References: <4B97C30F.5060200@jku.at> <1268308719.2124.7.camel@macbook>
Message-ID: <4B99063C.30605@jku.at>

Yes, the coro patch should be applied without continuations.
It doesn't need any of the continuation functionality - maybe I should 
make that more clear in the series file...
- Lukas

On 11.03.2010 12:58, Christian Thalinger wrote:
> On Wed, 2010-03-10 at 17:04 +0100, Lukas Stadler wrote:
>    
>> Hi everybody!
>>
>> As you've probably seen I've pushed a new coroutine implementation into
>> the repository.
>>      
> I'm just rebasing the mlvm patches to the latest code drop and HotSpot's
> coro.patch does not apply cleanly on top of the other patches (I think
> it's callcc.patch).  Is that intentional?  Should coro only be applied
> without callcc?
>
> -- Christian
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>    


From headius at headius.com  Thu Mar 11 17:20:08 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Thu, 11 Mar 2010 19:20:08 -0600
Subject: coroutines
In-Reply-To: <4B99063C.30605@jku.at>
References: <4B97C30F.5060200@jku.at> <1268308719.2124.7.camel@macbook> 
	<4B99063C.30605@jku.at>
Message-ID: <f04d2211003111720m54aceb2bk6d5315d12870b80b@mail.gmail.com>

And I'm almost exclusively interested in coro :)

On Thu, Mar 11, 2010 at 9:03 AM, Lukas Stadler <lukas.stadler at jku.at> wrote:
> Yes, the coro patch should be applied without continuations.
> It doesn't need any of the continuation functionality - maybe I should
> make that more clear in the series file...
> - Lukas
>
> On 11.03.2010 12:58, Christian Thalinger wrote:
>> On Wed, 2010-03-10 at 17:04 +0100, Lukas Stadler wrote:
>>
>>> Hi everybody!
>>>
>>> As you've probably seen I've pushed a new coroutine implementation into
>>> the repository.
>>>
>> I'm just rebasing the mlvm patches to the latest code drop and HotSpot's
>> coro.patch does not apply cleanly on top of the other patches (I think
>> it's callcc.patch). ?Is that intentional? ?Should coro only be applied
>> without callcc?
>>
>> -- Christian
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>

From Christian.Thalinger at Sun.COM  Fri Mar 12 05:21:25 2010
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Fri, 12 Mar 2010 14:21:25 +0100
Subject: Nullpointers not checked
In-Reply-To: <1268040638.27679.12.camel@macbook>
References: <m2hbospng1.fsf@gmail.com> <1268040638.27679.12.camel@macbook>
Message-ID: <1268400085.22991.22.camel@macbook>

On Mon, 2010-03-08 at 10:30 +0100, Christian Thalinger wrote:
> On Sun, 2010-03-07 at 09:04 +0100, Helmut Eller wrote:
> > The attached program crashes with this message:
> > 
> > #
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > #  Internal Error (sharedRuntime.cpp:586), pid=4116, tid=3072834448
> > #  Error: guarantee(cb->is_adapter_blob(),"exception happened outside interpreter, nmethods and vtable stubs (1)")
> > #
> > # JRE version: 7.0
> > # Java VM: OpenJDK Server VM (17.0-b05 interpreted mode linux-x86 )
> > # An error report file with more information is saved as:
> > # /tmp/hs_err_pid4116.log
> 
> Yes, that is a bug.  The null-pointer check is there but the implicit
> null-pointer exception in the MethodHandle adapter is not recognized.
> 
> I will fix that as part of 6932091.

The fix got bigger than I thought so I created a new bug for this:

6934494: JSR 292 MethodHandles adapters should be generated into their
own CodeBlob

Review will happen on the hotspot-compiler-dev alias.

-- Christian


From eller.helmut at gmail.com  Fri Mar 12 07:32:05 2010
From: eller.helmut at gmail.com (Helmut Eller)
Date: Fri, 12 Mar 2010 16:32:05 +0100
Subject: Nullpointers not checked
References: <m2hbospng1.fsf@gmail.com> <1268040638.27679.12.camel@macbook>
	<1268400085.22991.22.camel@macbook>
Message-ID: <m27hphbloq.fsf@gmail.com>

* Christian Thalinger [2010-03-12 14:21+0100] writes:

> 6934494: JSR 292 MethodHandles adapters should be generated into their
> own CodeBlob

Are those numbers a kind of bug ticket or some Sun internal thing?
I tried to search it on the OpenJDK Bugzilla but it only answered:
"Zarro Boogs found".

Helmut


From Christian.Thalinger at Sun.COM  Fri Mar 12 08:07:13 2010
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Fri, 12 Mar 2010 17:07:13 +0100
Subject: Nullpointers not checked
In-Reply-To: <m27hphbloq.fsf@gmail.com>
References: <m2hbospng1.fsf@gmail.com> <1268040638.27679.12.camel@macbook>
	<1268400085.22991.22.camel@macbook> <m27hphbloq.fsf@gmail.com>
Message-ID: <1268410033.22991.29.camel@macbook>

On Fri, 2010-03-12 at 16:32 +0100, Helmut Eller wrote:
> * Christian Thalinger [2010-03-12 14:21+0100] writes:
> 
> > 6934494: JSR 292 MethodHandles adapters should be generated into their
> > own CodeBlob
> 
> Are those numbers a kind of bug ticket or some Sun internal thing?
> I tried to search it on the OpenJDK Bugzilla but it only answered:
> "Zarro Boogs found".

Internally we use a different bug database.  It can be searched via:

http://bugs.sun.com/

But you have to wait about one day for the bug to be visible on the
public website.

-- Christian


From headius at headius.com  Mon Mar 15 16:43:14 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Mon, 15 Mar 2010 17:43:14 -0600
Subject: Need a jsr292-backport update?
Message-ID: <f04d2211003151643w6c9cac23tead51d9b8dab1706@mail.gmail.com>

Hey, I'm trying to update JRuby for all the changes to the java.dyn
APIs over the past few months, and it looks like the jsr292 backport
needs to be updated. R?mi: You out there? Do you have plans to update
it?

- Charlie

From headius at headius.com  Mon Mar 15 19:37:39 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Mon, 15 Mar 2010 20:37:39 -0600
Subject: Getting back into invokedynamic in JRuby
Message-ID: <f04d2211003151937n7cb82580udd55687241dac9d8@mail.gmail.com>

Hello all!

I'm finally getting back into invokedynamic/mlvm stuff in JRuby! I
have started updating our indy support and run into a few questions...

I was under the impression that JavaMethod handle would be a good way
to replace all the handle composition I was doing before. Is this
true?

I will explain...

Previously, when bootstrapping a call site, I used all MethodHandles.*
methods to compose a chain of direct method handles from the call site
all the way to the target method object, with no non-leaf Java code in
that call path. This was necessary, I believed, to allow inlining all
the way through the dynamic call site.

The structure was roughly like this:

Guard With Test
  Test (leaf Java method
  Success path
    Various chained handles to unpack arguments (via leaf Java methods)
      Actual target method
  Fail path
    Recache and invoke (non-leaf Java method

For the success path, it would then be all direct handles straight
through from caller to called method.

The logic for this version can be seen here:

http://github.com/jruby/jruby/blob/master/src/org/jruby/runtime/invokedynamic/InvokeDynamicSupport.java

This structure seemed to work well last fall, and on most
microbenchmarks it was as fast or faster than the trampolining version
in non-indy JRuby (where a CachingCallSite sits directly in the call
path). However, when I ran this code on current MLVM, the performance
was extremely slow...as much as ten times slower than it had been (and
ten times slower than my non-indy logic).

So today I did a rework using a Java method handle and all the
caching+call logic built directly into the handle I provide it. This
drastically reduced the complexity of my invokedynamic logic (since I
didn't have to do all that handle composition) and improved
performance, but it's still not as fast as last fall's MLVM plus the
composed handles.

You can see the new version here:

http://github.com/jruby/jruby/blob/indy/src/org/jruby/runtime/invokedynamic/InvokeDynamicSupport.java

I'm trying to find the right way to phrase my question to make sure I
get the right answer...

1. Do I need to use all direct method handles to get inlining from the
caller to the callee?
2. If I have a Java method handle that does a MethodHandle.invoke call
in its body, will that invoked handle get inlined all the way back for
all callers?
3. Does the body of the method pointed at by a JavaMethodHandle get
specialized for all call sites, so that it doesn't appear to be a
single body of code with a megamorphic invocation of a separate
handle?

Am I making my question clear enough?

Also, additional questions:

4. I still needed to bump up inlining budgets considerably to get
anything to inline across the dynamic call. Will that always be the
case, or is there still a plan to get dynamic call plumbing excluded
from that budget?
5. What can I do to investigate why current MLVM is, in all cases,
slower than what we had last fall?

I'm very interested in getting this stuff going again.

- Charlie

From forax at univ-mlv.fr  Tue Mar 16 01:49:29 2010
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Tue, 16 Mar 2010 09:49:29 +0100
Subject: Need a jsr292-backport update?
In-Reply-To: <f04d2211003151643w6c9cac23tead51d9b8dab1706@mail.gmail.com>
References: <f04d2211003151643w6c9cac23tead51d9b8dab1706@mail.gmail.com>
Message-ID: <4B9F4619.90706@univ-mlv.fr>

Le 16/03/2010 00:43, Charles Oliver Nutter a ?crit :
> Hey, I'm trying to update JRuby for all the changes to the java.dyn
> APIs over the past few months, and it looks like the jsr292 backport
> needs to be updated. R?mi: You out there? Do you have plans to update
> it?
>    

yes, the backport need to be updated,
I should have done that a long time ago.
I will try to find time next week-end to update it.

> - Charlie
>    

cheers,
R?mi

From forax at univ-mlv.fr  Tue Mar 16 08:22:02 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 16 Mar 2010 16:22:02 +0100
Subject: Getting back into invokedynamic in JRuby
In-Reply-To: <f04d2211003151937n7cb82580udd55687241dac9d8@mail.gmail.com>
References: <f04d2211003151937n7cb82580udd55687241dac9d8@mail.gmail.com>
Message-ID: <4B9FA21A.6030608@univ-mlv.fr>

Le 16/03/2010 03:37, Charles Oliver Nutter a ?crit :
> Hello all!
>    

Helllo Charles,
comment inlined.

> I'm finally getting back into invokedynamic/mlvm stuff in JRuby! I
> have started updating our indy support and run into a few questions...
>
> I was under the impression that JavaMethod handle would be a good way
> to replace all the handle composition I was doing before. Is this
> true?
>
> I will explain...
>
> Previously, when bootstrapping a call site, I used all MethodHandles.*
> methods to compose a chain of direct method handles from the call site
> all the way to the target method object, with no non-leaf Java code in
> that call path. This was necessary, I believed, to allow inlining all
> the way through the dynamic call site.
>
> The structure was roughly like this:
>
> Guard With Test
>    Test (leaf Java method
>    Success path
>      Various chained handles to unpack arguments (via leaf Java methods)
>        Actual target method
>    Fail path
>      Recache and invoke (non-leaf Java method
>
> For the success path, it would then be all direct handles straight
> through from caller to called method.
>
> The logic for this version can be seen here:
>
> http://github.com/jruby/jruby/blob/master/src/org/jruby/runtime/invokedynamic/InvokeDynamicSupport.java
>
> This structure seemed to work well last fall, and on most
> microbenchmarks it was as fast or faster than the trampolining version
> in non-indy JRuby (where a CachingCallSite sits directly in the call
> path). However, when I ran this code on current MLVM, the performance
> was extremely slow...as much as ten times slower than it had been (and
> ten times slower than my non-indy logic).
>
> So today I did a rework using a Java method handle and all the
> caching+call logic built directly into the handle I provide it. This
> drastically reduced the complexity of my invokedynamic logic (since I
> didn't have to do all that handle composition) and improved
> performance, but it's still not as fast as last fall's MLVM plus the
> composed handles.
>
> You can see the new version here:
>
> http://github.com/jruby/jruby/blob/indy/src/org/jruby/runtime/invokedynamic/InvokeDynamicSupport.java
>
> I'm trying to find the right way to phrase my question to make sure I
> get the right answer...
>
> 1. Do I need to use all direct method handles to get inlining from the
> caller to the callee?
>    

Yes.

> 2. If I have a Java method handle that does a MethodHandle.invoke call
> in its body, will that invoked handle get inlined all the way back for
> all callers?
>    

Neither the backport nor the RI do that.
It's a complex optimization involving to track method handle identity 
across method boundary.
This is doable but not currently done.
My hope is to come with an implementation doing that for the backport 
for the next JVM summit :)

Currently if you want the best performance, it's better to avoid direct 
method handle invocation
in the middle of an indy call.


> 3. Does the body of the method pointed at by a JavaMethodHandle get
> specialized for all call sites, so that it doesn't appear to be a
> single body of code with a megamorphic invocation of a separate
> handle?
>    

I've taken a look to your code and think you could again simplify it.
You don't use createGWT anymore and simulate it in all method invoke*
of CacheHandle.
In my opinion, this is not a good idea because:
- the cached method handle should be stored in the GWT
    (basicaly you don't need the object CacheEntry)
- the fast path should not use any trampoline code (any of your method 
invoke*)
   to be adapted to any signature.


> Am I making my question clear enough?
>
> Also, additional questions:
>
> 4. I still needed to bump up inlining budgets considerably to get
> anything to inline across the dynamic call. Will that always be the
> case, or is there still a plan to get dynamic call plumbing excluded
> from that budget?
> 5. What can I do to investigate why current MLVM is, in all cases,
> slower than what we had last fall?
>    

I don't know :)

> I'm very interested in getting this stuff going again.
>
> - Charlie
>    

R?mi

From Christian.Thalinger at Sun.COM  Tue Mar 16 08:24:10 2010
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Tue, 16 Mar 2010 16:24:10 +0100
Subject: Getting back into invokedynamic in JRuby
In-Reply-To: <f04d2211003151937n7cb82580udd55687241dac9d8@mail.gmail.com>
References: <f04d2211003151937n7cb82580udd55687241dac9d8@mail.gmail.com>
Message-ID: <1268753050.26240.20.camel@macbook>

On Mon, 2010-03-15 at 20:37 -0600, Charles Oliver Nutter wrote:
> I'm trying to find the right way to phrase my question to make sure I
> get the right answer...
> 
> 1. Do I need to use all direct method handles to get inlining from the
> caller to the callee?
> 2. If I have a Java method handle that does a MethodHandle.invoke call
> in its body, will that invoked handle get inlined all the way back for
> all callers?
> 3. Does the body of the method pointed at by a JavaMethodHandle get
> specialized for all call sites, so that it doesn't appear to be a
> single body of code with a megamorphic invocation of a separate
> handle?
> 
> Am I making my question clear enough?

I don't think I can really answer these questions, someone else can
probably do better.

> Also, additional questions:
> 
> 4. I still needed to bump up inlining budgets considerably to get
> anything to inline across the dynamic call. Will that always be the
> case, or is there still a plan to get dynamic call plumbing excluded
> from that budget?

We changed something about inlining depth, but you probably still have
to use InlineSmallCode to get all methods on the path inlined.

> 5. What can I do to investigate why current MLVM is, in all cases,
> slower than what we had last fall?

Look at the inline tree.  Is the slowdown happening with a particular
benchmark or with all of them?  We can have a look when you're online on
IRC again.

-- Christian


From szegedia at gmail.com  Wed Mar 17 03:54:24 2010
From: szegedia at gmail.com (Attila Szegedi)
Date: Wed, 17 Mar 2010 11:54:24 +0100
Subject: method handles and call sites listed as part of Java SE 6 Update 18?!
Message-ID: <8BF379E0-E277-4DBB-A2E1-CE21888479FE@gmail.com>

Folks,

just noticed something strange. Java SE 6 Update 18 Release Notes at <http://java.sun.com/javase/6/webnotes/6u18.html> list the following issues as being fixed for that release:

6655638  	hotspot 	compiler2 	dynamic languages need method handles
6655646  	hotspot 	compiler2 	dynamic languages need dynamically linked call sites 

What does this mean? Certainly it doesn't mean we suddenly got invokedynamic JVM support in Java 6, does it?

Attila.

From Christian.Thalinger at Sun.COM  Wed Mar 17 04:06:08 2010
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Wed, 17 Mar 2010 12:06:08 +0100
Subject: method handles and call sites listed as part of Java SE 6 Update
	18?!
In-Reply-To: <8BF379E0-E277-4DBB-A2E1-CE21888479FE@gmail.com>
References: <8BF379E0-E277-4DBB-A2E1-CE21888479FE@gmail.com>
Message-ID: <1268823968.26240.36.camel@macbook>

On Wed, 2010-03-17 at 11:54 +0100, Attila Szegedi wrote:
> Folks,
> 
> just noticed something strange. Java SE 6 Update 18 Release Notes at <http://java.sun.com/javase/6/webnotes/6u18.html> list the following issues as being fixed for that release:
> 
> 6655638  	hotspot 	compiler2 	dynamic languages need method handles
> 6655646  	hotspot 	compiler2 	dynamic languages need dynamically linked call sites 
> 
> What does this mean? Certainly it doesn't mean we suddenly got invokedynamic JVM support in Java 6, does it?

No.  As the release notes say:

"6u18 includes version 16.0 of the Java HotSpot Virtual Machine."

HotSpot Express is shipped with JDK 6 and 7 and that's why HotSpot
contains JSR 292 code.  But the JDK does not.

-- Christian


From szegedia at gmail.com  Wed Mar 17 04:47:35 2010
From: szegedia at gmail.com (Attila Szegedi)
Date: Wed, 17 Mar 2010 12:47:35 +0100
Subject: method handles and call sites listed as part of Java SE 6 Update
	18?!
In-Reply-To: <1268823968.26240.36.camel@macbook>
References: <8BF379E0-E277-4DBB-A2E1-CE21888479FE@gmail.com>
	<1268823968.26240.36.camel@macbook>
Message-ID: <AB468DC7-599E-424F-8CA0-B068F4CAC348@gmail.com>

On 2010.03.17., at 12:06, Christian Thalinger wrote:

> On Wed, 2010-03-17 at 11:54 +0100, Attila Szegedi wrote:
>> Folks,
>> 
>> just noticed something strange. Java SE 6 Update 18 Release Notes at <http://java.sun.com/javase/6/webnotes/6u18.html> list the following issues as being fixed for that release:
>> 
>> 6655638  	hotspot 	compiler2 	dynamic languages need method handles
>> 6655646  	hotspot 	compiler2 	dynamic languages need dynamically linked call sites 
>> 
>> What does this mean? Certainly it doesn't mean we suddenly got invokedynamic JVM support in Java 6, does it?
> 
> No.  As the release notes say:
> 
> "6u18 includes version 16.0 of the Java HotSpot Virtual Machine."
> 
> HotSpot Express is shipped with JDK 6 and 7 and that's why HotSpot
> contains JSR 292 code.  But the JDK does not.

Actually, that was exactly what I asked - I worded it carefully to say "JVM", not "JRE". So, the HotSpot JVM in there does ship with the JSR-292 bits, it's just that none of the java.dyn.* classes are in rt.jar, so the functionality is essentially dormant as there's no API entry point.

Hm... how long before someone gets an idea? :-)

Attila.

> 
> -- Christian

From thobes at gmail.com  Wed Mar 17 07:13:28 2010
From: thobes at gmail.com (Tobias Ivarsson)
Date: Wed, 17 Mar 2010 15:13:28 +0100
Subject: method handles and call sites listed as part of Java SE 6 Update 
	18?!
In-Reply-To: <AB468DC7-599E-424F-8CA0-B068F4CAC348@gmail.com>
References: <8BF379E0-E277-4DBB-A2E1-CE21888479FE@gmail.com> 
	<1268823968.26240.36.camel@macbook>
	<AB468DC7-599E-424F-8CA0-B068F4CAC348@gmail.com>
Message-ID: <9997d5e61003170713p37031d45oa48be88d0cce69cd@mail.gmail.com>

On Wed, Mar 17, 2010 at 12:47 PM, Attila Szegedi <szegedia at gmail.com> wrote:

> On 2010.03.17., at 12:06, Christian Thalinger wrote:
>
> > On Wed, 2010-03-17 at 11:54 +0100, Attila Szegedi wrote:
> >> Folks,
> >>
> >> just noticed something strange. Java SE 6 Update 18 Release Notes at <
> http://java.sun.com/javase/6/webnotes/6u18.html> list the following issues
> as being fixed for that release:
> >>
> >> 6655638      hotspot         compiler2       dynamic languages need
> method handles
> >> 6655646      hotspot         compiler2       dynamic languages need
> dynamically linked call sites
> >>
> >> What does this mean? Certainly it doesn't mean we suddenly got
> invokedynamic JVM support in Java 6, does it?
> >
> > No.  As the release notes say:
> >
> > "6u18 includes version 16.0 of the Java HotSpot Virtual Machine."
> >
> > HotSpot Express is shipped with JDK 6 and 7 and that's why HotSpot
> > contains JSR 292 code.  But the JDK does not.
>
> Actually, that was exactly what I asked - I worded it carefully to say
> "JVM", not "JRE". So, the HotSpot JVM in there does ship with the JSR-292
> bits, it's just that none of the java.dyn.* classes are in rt.jar, so the
> functionality is essentially dormant as there's no API entry point.
>
> Hm... how long before someone gets an idea? :-)
>

Ooo... that gives me an idea ;-)

I'm pretty sure everyone on this list also got this idea: putting a jar
containing the java.dyn stuff on the bootclasspath should give us
invokedynamic support...

I haven't tried it, there might be other issues preventing it, I just
couldn't resist the "how long before someone gets an idea?" trap you set...

/Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100317/227aaa61/attachment.html 

From forax at univ-mlv.fr  Wed Mar 17 08:07:13 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 17 Mar 2010 16:07:13 +0100
Subject: method handles and call sites listed as part of Java SE 6 Update
	18?!
In-Reply-To: <9997d5e61003170713p37031d45oa48be88d0cce69cd@mail.gmail.com>
References: <8BF379E0-E277-4DBB-A2E1-CE21888479FE@gmail.com>
	<1268823968.26240.36.camel@macbook>	<AB468DC7-599E-424F-8CA0-B068F4CAC348@gmail.com>
	<9997d5e61003170713p37031d45oa48be88d0cce69cd@mail.gmail.com>
Message-ID: <4BA0F021.7050402@univ-mlv.fr>

Le 17/03/2010 15:13, Tobias Ivarsson a ?crit :
>
> On Wed, Mar 17, 2010 at 12:47 PM, Attila Szegedi <szegedia at gmail.com 
> <mailto:szegedia at gmail.com>> wrote:
>
>     On 2010.03.17., at 12:06, Christian Thalinger wrote:
>
>     > On Wed, 2010-03-17 at 11:54 +0100, Attila Szegedi wrote:
>     >> Folks,
>     >>
>     >> just noticed something strange. Java SE 6 Update 18 Release
>     Notes at <http://java.sun.com/javase/6/webnotes/6u18.html> list
>     the following issues as being fixed for that release:
>     >>
>     >> 6655638      hotspot         compiler2       dynamic languages
>     need method handles
>     >> 6655646      hotspot         compiler2       dynamic languages
>     need dynamically linked call sites
>     >>
>     >> What does this mean? Certainly it doesn't mean we suddenly got
>     invokedynamic JVM support in Java 6, does it?
>     >
>     > No.  As the release notes say:
>     >
>     > "6u18 includes version 16.0 of the Java HotSpot Virtual Machine."
>     >
>     > HotSpot Express is shipped with JDK 6 and 7 and that's why HotSpot
>     > contains JSR 292 code.  But the JDK does not.
>
>     Actually, that was exactly what I asked - I worded it carefully to
>     say "JVM", not "JRE". So, the HotSpot JVM in there does ship with
>     the JSR-292 bits, it's just that none of the java.dyn.* classes
>     are in rt.jar, so the functionality is essentially dormant as
>     there's no API entry point.
>
>     Hm... how long before someone gets an idea? :-)
>
>
> Ooo... that gives me an idea ;-)
>
> I'm pretty sure everyone on this list also got this idea: putting a 
> jar containing the java.dyn stuff on the bootclasspath should give us 
> invokedynamic support...
>
> I haven't tried it, there might be other issues preventing it, I just 
> couldn't resist the "how long before someone gets an idea?" trap you 
> set...
>
> /Tobias

Don't forget to set some flags when starting the VM :)

-server -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic

R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100317/dc53bca6/attachment.html 

From Christian.Thalinger at Sun.COM  Wed Mar 17 10:49:34 2010
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Wed, 17 Mar 2010 18:49:34 +0100
Subject: SPARC JSR 292 testing
Message-ID: <1268848174.26240.44.camel@macbook>

Does anyone here have SPARC hardware?  It would be very nice to get some
testing of the interpreter port on that architecture.

-- Christian


From John.Rose at Sun.COM  Wed Mar 17 11:51:02 2010
From: John.Rose at Sun.COM (John Rose)
Date: Wed, 17 Mar 2010 11:51:02 -0700
Subject: method handles and call sites listed as part of Java SE 6 Update
	18?!
In-Reply-To: <9997d5e61003170713p37031d45oa48be88d0cce69cd@mail.gmail.com>
References: <8BF379E0-E277-4DBB-A2E1-CE21888479FE@gmail.com>
	<1268823968.26240.36.camel@macbook>
	<AB468DC7-599E-424F-8CA0-B068F4CAC348@gmail.com>
	<9997d5e61003170713p37031d45oa48be88d0cce69cd@mail.gmail.com>
Message-ID: <BE7C2B83-051F-4D1E-8E35-BD1091C6925F@sun.com>

On Mar 17, 2010, at 7:13 AM, Tobias Ivarsson wrote:

> I haven't tried it, there might be other issues preventing it

The main issue preventing it is that rt.jar is tightly coupled to the JVM it is delivered with; put another way, the interface between the java.dyn classes and the JVM is unspecified and subject to change.  Thus, it is hit or miss whether you can run any given "naked JVM" containing 292 with some proposed extract of 292 functionality from some rt.jar.

A second issue is that the 292 EG is still refining the spec.  The next few pushes to the mlvm patches (and later to the OpenJDK builds) will incompatibly change some APIs.  The bootstrap API is being simplified and 'invoke' is being renamed 'invokeExact' (and being joined by a fraternal twin, 'invokeGeneric').

Stay tuned...

-- John

From John.Rose at Sun.COM  Wed Mar 17 11:58:06 2010
From: John.Rose at Sun.COM (John Rose)
Date: Wed, 17 Mar 2010 11:58:06 -0700
Subject: SPARC JSR 292 testing
In-Reply-To: <1268848174.26240.44.camel@macbook>
References: <1268848174.26240.44.camel@macbook>
Message-ID: <376A1283-4196-4CDA-B407-E8F3F342033F@sun.com>

For "here" equal to ??

When on our intranet I use karachi.sfbay.sun.com as a server which is located in Santa Clara.

-- John

P.S.  To make forays off my laptop, I usually have a Gnu emacs X server running on the target machine, under a Gnu 'screen' instance.

On Mar 17, 2010, at 10:49 AM, Christian Thalinger wrote:

> Does anyone here have SPARC hardware?  It would be very nice to get some
> testing of the interpreter port on that architecture.
> 
> -- Christian


From forax at univ-mlv.fr  Wed Mar 17 12:07:15 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 17 Mar 2010 20:07:15 +0100
Subject: method handles and call sites listed as part of Java SE 6 Update
	18?!
In-Reply-To: <BE7C2B83-051F-4D1E-8E35-BD1091C6925F@sun.com>
References: <8BF379E0-E277-4DBB-A2E1-CE21888479FE@gmail.com>	<1268823968.26240.36.camel@macbook>	<AB468DC7-599E-424F-8CA0-B068F4CAC348@gmail.com>	<9997d5e61003170713p37031d45oa48be88d0cce69cd@mail.gmail.com>
	<BE7C2B83-051F-4D1E-8E35-BD1091C6925F@sun.com>
Message-ID: <4BA12863.1080006@univ-mlv.fr>

Le 17/03/2010 19:51, John Rose a ?crit :
> On Mar 17, 2010, at 7:13 AM, Tobias Ivarsson wrote:
>
>    
>> I haven't tried it, there might be other issues preventing it
>>      
> The main issue preventing it is that rt.jar is tightly coupled to the JVM it is delivered with; put another way, the interface between the java.dyn classes and the JVM is unspecified and subject to change.  Thus, it is hit or miss whether you can run any given "naked JVM" containing 292 with some proposed extract of 292 functionality from some rt.jar.
>
> A second issue is that the 292 EG is still refining the spec.  The next few pushes to the mlvm patches (and later to the OpenJDK builds) will incompatibly change some APIs.  The bootstrap API is being simplified and 'invoke' is being renamed 'invokeExact' (and being joined by a fraternal twin, 'invokeGeneric').
>    

I prefer to see invokeGeneric as a the dark side twin,
more powerful but without a clear performance guarantee :)

> Stay tuned...
>
> -- John
>    

R?mi

From Christian.Thalinger at Sun.COM  Wed Mar 17 12:11:49 2010
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Wed, 17 Mar 2010 20:11:49 +0100
Subject: SPARC JSR 292 testing
In-Reply-To: <376A1283-4196-4CDA-B407-E8F3F342033F@sun.com>
References: <1268848174.26240.44.camel@macbook>
	<376A1283-4196-4CDA-B407-E8F3F342033F@sun.com>
Message-ID: <1268853109.26240.47.camel@macbook>

On Wed, 2010-03-17 at 11:58 -0700, John Rose wrote:
> For "here" equal to ??

...not me :-)  It just would be nice to have some other testing than
what I do, which is always the same.

-- Christian


From Dalibor.Topic at Sun.COM  Wed Mar 17 13:22:15 2010
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Wed, 17 Mar 2010 21:22:15 +0100
Subject: SPARC JSR 292 testing
In-Reply-To: <1268853109.26240.47.camel@macbook>
References: <1268848174.26240.44.camel@macbook>
	<376A1283-4196-4CDA-B407-E8F3F342033F@sun.com>
	<1268853109.26240.47.camel@macbook>
Message-ID: <4BA139F7.5010704@sun.com>

Christian Thalinger wrote:
> On Wed, 2010-03-17 at 11:58 -0700, John Rose wrote:
>> For "here" equal to ??
> 
> ...not me :-)  It just would be nice to have some other testing than
> what I do, which is always the same.
> 

See http://people.debian.org/~aurel32/qemu/sparc/ for Debian Etch
images for sparc32 for QEMU.

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?er



From headius at headius.com  Fri Mar 19 08:59:57 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Fri, 19 Mar 2010 10:59:57 -0500
Subject: Move some indy stuff to javax package?
Message-ID: <f04d2211003190859u2c154829jae8784140ad35755@mail.gmail.com>

It occurred to me today that if we had more of java.dyn in a javax
package, we'd be able to ship a backported jar that doesn't require
rewriting everything on load. As it stands right now, everything I
write that touches java.dyn has to be duplicated and usually
reflectively loaded, since those classes won't be present on Java 5/6
JVMs.

So, has this idea been discussed before?

- Charlie

From headius at headius.com  Fri Mar 19 09:21:39 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Fri, 19 Mar 2010 11:21:39 -0500
Subject: Getting back into invokedynamic in JRuby
In-Reply-To: <4B9FA21A.6030608@univ-mlv.fr>
References: <f04d2211003151937n7cb82580udd55687241dac9d8@mail.gmail.com> 
	<4B9FA21A.6030608@univ-mlv.fr>
Message-ID: <f04d2211003190921g4f742955u9e154f406f9e0c87@mail.gmail.com>

On Tue, Mar 16, 2010 at 10:22 AM, R?mi Forax <forax at univ-mlv.fr> wrote:
> Le 16/03/2010 03:37, Charles Oliver Nutter a ?crit :
>> 1. Do I need to use all direct method handles to get inlining from the
>> caller to the callee?
>>
>
> Yes.
>
>> 2. If I have a Java method handle that does a MethodHandle.invoke call
>> in its body, will that invoked handle get inlined all the way back for
>> all callers?
>>
>
> Neither the backport nor the RI do that.
> It's a complex optimization involving to track method handle identity
> across method boundary.
> This is doable but not currently done.
> My hope is to come with an implementation doing that for the backport
> for the next JVM summit :)
>
> Currently if you want the best performance, it's better to avoid direct
> method handle invocation
> in the middle of an indy call.

Ok, so basically, nothing in either the backport nor the RI
(currently) can do anything if a piece of Java code (real Java!) in
the middle of a chain ends up doing polymorphic calls, even if those
polymorphic calls are directly into other handles. And you would like
to prototype specializing such cases.

This fits my assumption of the state of the world. I'll probably dump
this new indy branch and go back to all direct handles, plus some
cleanup as you suggest.

The specialization case is interesting for another reason, though:
closure conversion. The simple example is array.each {|x| puts x}
where you'd like both each and the block to inline into the caller.
Currently, since each will certainly receive many different closures,
the call from each to the closures is polymorphic, and so only each
itself can get inlined back. Given that so many of the new JVM
languages (all?) support (and encourage!) closures, this is going to
be a growing problem. The JRockit folks seemed to think it wouldn't be
hard to modify JRockit to handle this case, but they indicated it
would be easiest if it were a standard parameter type or call target
for the closure (like a MethodHandle, for example).

> I've taken a look to your code and think you could again simplify it.
> You don't use createGWT anymore and simulate it in all method invoke*
> of CacheHandle.
> In my opinion, this is not a good idea because:
> - the cached method handle should be stored in the GWT
> ? ?(basicaly you don't need the object CacheEntry)
> - the fast path should not use any trampoline code (any of your method
> invoke*)
> ? to be adapted to any signature.

So if I understand your suggestion, you think the new version of the
code could be used if the fast path itself was all direct handles as
before. I think that puts me pretty much back on the original code,
where the slow path used a pure-Java "fallback" trampoline and the
fast path was a straight-through chain of direct handles all the way
to the target.

>> 4. I still needed to bump up inlining budgets considerably to get
>> anything to inline across the dynamic call. Will that always be the
>> case, or is there still a plan to get dynamic call plumbing excluded
>> from that budget?
>> 5. What can I do to investigate why current MLVM is, in all cases,
>> slower than what we had last fall?

FYI, Christian put me back on the right track. The inlining budgets
are definitely still coming into play, and indy performs as expected
(slightly faster than non-indy) if I additionally add
+MaxInlineSize=50 and +InlineSmallCode=2500. So the original code is
still OK.

- Charlie

From Christian.Thalinger at Sun.COM  Mon Mar 22 03:14:53 2010
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Mon, 22 Mar 2010 10:14:53 +0000
Subject: hg: mlvm/mlvm/hotspot: Rebased to jdk7-b86.
Message-ID: <20100322101455.5FDC144642@hg.openjdk.java.net>

Changeset: fde8521f9c12
Author:    twisti
Date:      2010-03-22 11:10 +0100
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/fde8521f9c12

Rebased to jdk7-b86.

! series


From Christian.Thalinger at Sun.COM  Mon Mar 22 03:15:33 2010
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Mon, 22 Mar 2010 10:15:33 +0000
Subject: hg: mlvm/mlvm/jdk: Rebased to jdk7-b86.
Message-ID: <20100322101534.1499044644@hg.openjdk.java.net>

Changeset: a59e2ac08802
Author:    twisti
Date:      2010-03-22 11:10 +0100
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/a59e2ac08802

Rebased to jdk7-b86.

! series


From Christian.Thalinger at Sun.COM  Mon Mar 22 03:15:48 2010
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Mon, 22 Mar 2010 10:15:48 +0000
Subject: hg: mlvm/mlvm/langtools: Rebased to jdk7-b86.
Message-ID: <20100322101548.E21F144645@hg.openjdk.java.net>

Changeset: 7cf9093b010b
Author:    twisti
Date:      2010-03-22 11:11 +0100
URL:       http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/7cf9093b010b

Rebased to jdk7-b86.

! series


From headius at headius.com  Mon Mar 22 22:17:23 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Tue, 23 Mar 2010 00:17:23 -0500
Subject: Dirt-simple dynamic dispatch bootstrapper built into JDK?
Message-ID: <f04d2211003222217r401213fam3fe904a5d33455d7@mail.gmail.com>

Hey, maybe I missed something, but it seems like there's a need for a
"default" invokedynamic bootstrap. For example, I hacked invokedynamic
bytecode emitting into Duby, so that this code:

def foo(a:dynamic)
  a.size
  a.elementAt(0)
end

Emits this bytecode:

  public static java.lang.Object foo(java.lang.Object);
    Code:
       0: aload_0
       1: invokedynamic #10,  0             // NameAndType
size:(Ljava/lang/Object;)Ljava/lang/Object;
       6: pop
       7: aload_0
       8: iconst_1
       9: invokedynamic #13,  0             // NameAndType
elementAt:(Ljava/lang/Object;I)Ljava/lang/Object;
      14: areturn

Now rather than me shipping my own bootstrapper that just does normal
Java method selection, it would be nice if there were one built into
the JDK. It seems like a lot of folks playing with invokedynamic will
want a simple fallback that just does Java invocation.

Is there anything like this in indy right now?

* Take the signature (minus the passed java/lang/Object) and try to
look up a method on the actual target
* If that fails, use the actual types of the arguments to perform the
same search
* If that fails, throw some interesting runtime error
* If we find a method, bind it with a simple class equality type guard
* Stack bindings for additional classes as they are encountered
possibly caching at a JVM level the sets of target+args we've seen

- Charlie

From szegedia at gmail.com  Tue Mar 23 01:07:03 2010
From: szegedia at gmail.com (Attila Szegedi)
Date: Tue, 23 Mar 2010 09:07:03 +0100
Subject: Dirt-simple dynamic dispatch bootstrapper built into JDK?
In-Reply-To: <f04d2211003222217r401213fam3fe904a5d33455d7@mail.gmail.com>
References: <f04d2211003222217r401213fam3fe904a5d33455d7@mail.gmail.com>
Message-ID: <5A46D5DE-6BCA-4C20-B40F-2686F8189945@gmail.com>

On 2010.03.23., at 6:17, Charles Oliver Nutter wrote:

> Hey, maybe I missed something, but it seems like there's a need for a
> "default" invokedynamic bootstrap. For example, I hacked invokedynamic
> bytecode emitting into Duby, so that this code:
> 
> def foo(a:dynamic)
>  a.size
>  a.elementAt(0)
> end
> 
> Emits this bytecode:
> 
>  public static java.lang.Object foo(java.lang.Object);
>    Code:
>       0: aload_0
>       1: invokedynamic #10,  0             // NameAndType
> size:(Ljava/lang/Object;)Ljava/lang/Object;
>       6: pop
>       7: aload_0
>       8: iconst_1
>       9: invokedynamic #13,  0             // NameAndType
> elementAt:(Ljava/lang/Object;I)Ljava/lang/Object;
>      14: areturn
> 
> Now rather than me shipping my own bootstrapper that just does normal
> Java method selection, it would be nice if there were one built into
> the JDK. It seems like a lot of folks playing with invokedynamic will
> want a simple fallback that just does Java invocation.
> 
> Is there anything like this in indy right now?

Nope, but there's in my MOP library :-)

> * Take the signature (minus the passed java/lang/Object) and try to
> look up a method on the actual target
> * If that fails, use the actual types of the arguments to perform the
> same search
> * If that fails, throw some interesting runtime error
> * If we find a method, bind it with a simple class equality type guard

This is pretty much what

<http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/invoke/src/org/dynalang/dynalink/beans/BeansLinker.java?revision=211&view=markup>

and its friend classes (SimpleDynamicMethod and OverloadedDynamicMethod) in the package do - linkage following Java linking rules, using actual argument types at runtime.  
 
> * Stack bindings for additional classes as they are encountered
> possibly caching at a JVM level the sets of target+args we've seen

Admittedly, I don't provide this, just a monomorphic relinkable call site at <http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/invoke/src/org/dynalang/dynalink/MonomorphicCallSite.java?revision=209&view=markup> but nothing stops you from taking its superclass RelinkableCallSite <http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/invoke/src/org/dynalang/dynalink/RelinkableCallSite.java?revision=187&view=markup> and rewrite it to support a cascade of guardWithTest()s for various target classes.

The OverloadedMethod class actually has an argTypesToMethods map, that caches argTypes->method selection for overloads. Each instance of OverloadedMethod is specific to (target class, call site signature) and only contains the subset of overloaded methods that are applicable for the particular call site signature; it'll dispatch based on argTypesToMethods map on each invocation - that's pretty much the best you can do in the case where multiple overloads match a call site signature... 

There's plenty of opportunities for various optimizations in there though. I.e. OverloadedMethod instances could be uniqued for call sites with identical signatures (they aren't currently because that can have memory management implications, so then that needs to be dealt with too). I'm favoring code clarity over speculative optimizations, and I'm favoring necessary optimizations over code clarity (if they can't be done preserving said clarity), so there's not much optimizations in there as I don't have information on necessary optimizations *yet*... (nudge, wink).


> - Charlie

Attila.

--
home: http://www.szegedi.org
twitter: http://twitter.com/szegedi
weblog: http://constc.blogspot.com

From headius at headius.com  Tue Mar 23 07:05:53 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Tue, 23 Mar 2010 09:05:53 -0500
Subject: Dirt-simple dynamic dispatch bootstrapper built into JDK?
In-Reply-To: <5A46D5DE-6BCA-4C20-B40F-2686F8189945@gmail.com>
References: <f04d2211003222217r401213fam3fe904a5d33455d7@mail.gmail.com>
	<5A46D5DE-6BCA-4C20-B40F-2686F8189945@gmail.com>
Message-ID: <643C4D3B-CA8F-4EA6-A671-E2824DCD0B5E@headius.com>

Thanks Attila! Given that I don't want to write my own dispatcher,  
your MOP will have it's first official customer in Duby. It will also  
have the dubious (pun intended) distinction of being Duby's first  
library dependency (only for dynamic invocation.

- Charlie (mobile)

On Mar 23, 2010, at 3:07 AM, Attila Szegedi <szegedia at gmail.com> wrote:

> On 2010.03.23., at 6:17, Charles Oliver Nutter wrote:
>
>> Hey, maybe I missed something, but it seems like there's a need for a
>> "default" invokedynamic bootstrap. For example, I hacked  
>> invokedynamic
>> bytecode emitting into Duby, so that this code:
>>
>> def foo(a:dynamic)
>> a.size
>> a.elementAt(0)
>> end
>>
>> Emits this bytecode:
>>
>> public static java.lang.Object foo(java.lang.Object);
>>   Code:
>>      0: aload_0
>>      1: invokedynamic #10,  0             // NameAndType
>> size:(Ljava/lang/Object;)Ljava/lang/Object;
>>      6: pop
>>      7: aload_0
>>      8: iconst_1
>>      9: invokedynamic #13,  0             // NameAndType
>> elementAt:(Ljava/lang/Object;I)Ljava/lang/Object;
>>     14: areturn
>>
>> Now rather than me shipping my own bootstrapper that just does normal
>> Java method selection, it would be nice if there were one built into
>> the JDK. It seems like a lot of folks playing with invokedynamic will
>> want a simple fallback that just does Java invocation.
>>
>> Is there anything like this in indy right now?
>
> Nope, but there's in my MOP library :-)
>
>> * Take the signature (minus the passed java/lang/Object) and try to
>> look up a method on the actual target
>> * If that fails, use the actual types of the arguments to perform the
>> same search
>> * If that fails, throw some interesting runtime error
>> * If we find a method, bind it with a simple class equality type  
>> guard
>
> This is pretty much what
>
> <http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/invoke/src/org/dynalang/dynalink/beans/BeansLinker.java?revision=211&view=markup 
> >
>
> and its friend classes (SimpleDynamicMethod and  
> OverloadedDynamicMethod) in the package do - linkage following Java  
> linking rules, using actual argument types at runtime.
>
>> * Stack bindings for additional classes as they are encountered
>> possibly caching at a JVM level the sets of target+args we've seen
>
> Admittedly, I don't provide this, just a monomorphic relinkable call  
> site at <http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/invoke/src/org/dynalang/dynalink/MonomorphicCallSite.java?revision=209&view=markup 
> > but nothing stops you from taking its superclass  
> RelinkableCallSite <http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/invoke/src/org/dynalang/dynalink/RelinkableCallSite.java?revision=187&view=markup 
> > and rewrite it to support a cascade of guardWithTest()s for  
> various target classes.
>
> The OverloadedMethod class actually has an argTypesToMethods map,  
> that caches argTypes->method selection for overloads. Each instance  
> of OverloadedMethod is specific to (target class, call site  
> signature) and only contains the subset of overloaded methods that  
> are applicable for the particular call site signature; it'll  
> dispatch based on argTypesToMethods map on each invocation - that's  
> pretty much the best you can do in the case where multiple overloads  
> match a call site signature...
>
> There's plenty of opportunities for various optimizations in there  
> though. I.e. OverloadedMethod instances could be uniqued for call  
> sites with identical signatures (they aren't currently because that  
> can have memory management implications, so then that needs to be  
> dealt with too). I'm favoring code clarity over speculative  
> optimizations, and I'm favoring necessary optimizations over code  
> clarity (if they can't be done preserving said clarity), so there's  
> not much optimizations in there as I don't have information on  
> necessary optimizations *yet*... (nudge, wink).
>
>
>> - Charlie
>
> Attila.
>
> --
> home: http://www.szegedi.org
> twitter: http://twitter.com/szegedi
> weblog: http://constc.blogspot.com
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

From john.rose at sun.com  Wed Mar 24 18:58:26 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 25 Mar 2010 01:58:26 +0000
Subject: hg: mlvm/mlvm: meth, indy: update 292 API; support ldc of MH
Message-ID: <20100325015826.A7A514420A@hg.openjdk.java.net>

Changeset: 1c7351d7192f
Author:    jrose
Date:      2010-03-24 18:57 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/rev/1c7351d7192f

meth, indy: update 292 API; support ldc of MH

! netbeans/indy-demo/build.xml
! netbeans/indy-demo/nbproject/project.properties
! netbeans/indy-demo/src/FidgetDemo.java
! netbeans/indy-demo/src/GetNameDemo.java
! netbeans/indy-demo/src/Hello.java
! netbeans/indy-demo/src/Main.java
! netbeans/indy-demo/src/ShouldNotWork.java
! netbeans/indy-demo/src/recipes/Curry.java
! netbeans/indy-demo/src/recipes/FastAndSlow.java
! netbeans/indy-demo/src/recipes/PlainOldJava.java
! netbeans/indy-demo/src/recipes/Utensil.java
! netbeans/meth/build.xml
! netbeans/meth/nbproject/build-impl.xml
! netbeans/meth/nbproject/genfiles.properties
! netbeans/meth/nbproject/project.properties
! netbeans/meth/nbproject/project.xml
= netbeans/meth/old-test/jdk/java/dyn/MethodHandlesTest.java < netbeans/meth/test/jdk/java/dyn/MethodHandlesTest.java


From john.rose at sun.com  Wed Mar 24 18:58:36 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 25 Mar 2010 01:58:36 +0000
Subject: hg: mlvm/mlvm/hotspot: meth, indy: update 292 API; support ldc of MH
Message-ID: <20100325015836.E67584420B@hg.openjdk.java.net>

Changeset: 5353e955d315
Author:    jrose
Date:      2010-03-24 18:47 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/5353e955d315

meth, indy: update 292 API; support ldc of MH

+ cpindex-cleanup.patch
+ meth-ing.patch
+ meth-ldc.patch
+ meth.fixes.patch
! meth.patch
! series


From john.rose at sun.com  Wed Mar 24 18:58:49 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 25 Mar 2010 01:58:49 +0000
Subject: hg: mlvm/mlvm/jdk: meth, indy: update 292 API; support ldc of MH
Message-ID: <20100325015850.4179B4420C@hg.openjdk.java.net>

Changeset: 9e4635f9c734
Author:    jrose
Date:      2010-03-24 18:41 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/9e4635f9c734

meth, indy: update 292 API; support ldc of MH

- indy.tests.patch
+ meth-ing.patch
+ meth-ldc.patch
! meth.patch
! meth.test.patch
! series


From john.rose at sun.com  Wed Mar 24 18:58:53 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 25 Mar 2010 01:58:53 +0000
Subject: hg: mlvm/mlvm/langtools: meth, indy: update 292 API; support ldc of MH
Message-ID: <20100325015853.9A5904420D@hg.openjdk.java.net>

Changeset: 823b57d82686
Author:    jrose
Date:      2010-03-24 18:36 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/823b57d82686

meth, indy: update 292 API; support ldc of MH

! compile-error-tweak.patch
! meth.patch
! series


From John.Rose at Sun.COM  Wed Mar 24 19:03:13 2010
From: John.Rose at Sun.COM (John Rose)
Date: Wed, 24 Mar 2010 19:03:13 -0700
Subject: JSR 292 API changes
Message-ID: <254BBAAC-79AE-4327-A2FD-5850814F0944@sun.com>

The JSR 292 EG has decided to simplify some aspects of the API.  I have just pushed updated patches to mlvm which embody these changes.

CallSite is more streamlined.  The only field it has is the target method handle.  The caller class, type, and name have gone away.    It is simple to create a CallSite subclass that remembers this information if you need it.  Here's an example usage:
  http://hg.openjdk.java.net/mlvm/mlvm/file/1c7351d7192f/netbeans/indy-demo/src/GetNameDemo.java

Also, ldc of method handle constants is now supported.  There is a patch in langtools with a prototype syntax to support this at the source level.

Note:  The updated patches to hotspot are untested on x86/64 and SPARC systems.

-- John

From headius at headius.com  Wed Mar 24 19:17:59 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Wed, 24 Mar 2010 21:17:59 -0500
Subject: Duby dynamic dispatch has landed!
Message-ID: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com>

I love Duby sometimes, I really do.

I've just landed full dynamic dispatch support. Here's an example
script and session:

~/projects/duby ? cat examples/dynamic.duby
# Example of using a dynamic type in a method definition
def foo(a:dynamic)
  puts "I got a #{a.getClass.getName} of size #{a.size}"
end

class SizeThing
  def initialize(size:int)
    @size = size
  end

  def size
    @size
  end
end

foo([1,2,3])
foo(SizeThing.new(12))

~/projects/duby ? bin/duby examples/dynamic.duby
I got a java.util.Collections$UnmodifiableRandomAccessList of size 3
I got a examples.SizeThing of size 12

I like this example because it's two totally disjoint types that
happen to both have a "size" method, and Duby + indy + dynalang
handles them just fine.

So far I'm doing it like C#, specifying a "dynamic" type that
propagates as-is through the type inference phase(s), but for bytecode
and signature generation it gets erased to java.lang.Object.

Here's log output of the number of lines added/removed for the entire
"dynamic" type feature in Duby's compiler chain:

http://gist.github.com/343072

Maybe a couple hundred lines of code? Of course I'm cheating by using
dynalang and indy, but hey, that's the right way to build software,
isn't it?

I'm pretty stoked how well this is working.

For Attila: I had to remove a spreadArguments handle you used for
re-binding the method...not sure why. Here's the diff:

Index: src/org/dynalang/dynalink/support/DynamicLinkerImpl.java
===================================================================
--- src/org/dynalang/dynalink/support/DynamicLinkerImpl.java	(revision 232)
+++ src/org/dynalang/dynalink/support/DynamicLinkerImpl.java	(working copy)
@@ -115,8 +115,6 @@
         final MethodType genericType = invocation.type().generic();
         final MethodHandle genericizedInvocation =
             MethodHandles.convertArguments(invocation, genericType);
-        final MethodHandle spreadInvocation = MethodHandles.spreadArguments(
-                genericizedInvocation, SPREAD_GENERIC_INVOCATION);
-        return MethodHandles.invoke(spreadInvocation, arguments);
+        return MethodHandles.invoke(genericizedInvocation, arguments);
     }
 }

I committed a built version with this hack...no tests, etc yet for
Duby's "dynamic" type, but that will come soon.

BTW, what's the current state of the art for emitting .java with an
invokedynamic in it? Duby also has a .java backend, so I'll need to
add indy support there as well (somehow).

- Charlie

From john.rose at sun.com  Wed Mar 24 21:31:31 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 25 Mar 2010 04:31:31 +0000
Subject: hg: mlvm/mlvm/langtools: meth, indy: update 292 API;
	support ldc of MH (new files)
Message-ID: <20100325043131.972A244237@hg.openjdk.java.net>

Changeset: e255930cc27f
Author:    jrose
Date:      2010-03-24 21:31 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/e255930cc27f

meth, indy: update 292 API; support ldc of MH (new files)

+ dump-stack-on-error.patch
+ meth-anno.patch
+ meth-ing.patch
+ meth-ldc.patch
+ netbeans-project.patch


From john.rose at sun.com  Wed Mar 24 21:35:05 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 25 Mar 2010 04:35:05 +0000
Subject: hg: mlvm/mlvm/hotspot: suggested ASM patch for ldc of MH
Message-ID: <20100325043505.23B8544238@hg.openjdk.java.net>

Changeset: 5bfecdeba374
Author:    jrose
Date:      2010-03-24 21:35 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/5bfecdeba374

suggested ASM patch for ldc of MH

+ asm/asm-jsr292-ldc.patch


From john.rose at sun.com  Wed Mar 24 21:44:44 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 25 Mar 2010 04:44:44 +0000
Subject: hg: mlvm/mlvm: indy: update code examples
Message-ID: <20100325044444.CAD614423C@hg.openjdk.java.net>

Changeset: 6801a67b2bfd
Author:    jrose
Date:      2010-03-24 21:44 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/rev/6801a67b2bfd

indy: update code examples

+ netbeans/indy-demo/src/JavaDocExamples.java
+ netbeans/indy-demo/src/PrintArgsDemo.java
+ netbeans/indy-demo/src/VMILDemos.java


From John.Rose at Sun.COM  Wed Mar 24 21:48:18 2010
From: John.Rose at Sun.COM (John Rose)
Date: Wed, 24 Mar 2010 21:48:18 -0700
Subject: Duby dynamic dispatch has landed!
In-Reply-To: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com>
References: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com>
Message-ID: <8A28E8BC-EC73-49A1-BE91-4BBDFA30B912@sun.com>

Very nice stuff.  Congratulations!

On Mar 24, 2010, at 7:17 PM, Charles Oliver Nutter wrote:

> BTW, what's the current state of the art for emitting .java with an
> invokedynamic in it? Duby also has a .java backend, so I'll need to
> add indy support there as well (somehow).

This statement:

	java.dyn.InvokeDynamic.<boolean>#"foo:bar"(1, 2.3, (Object)four);

compiles to code ending in this instruction:

	invokedynamic "foo:bar", (IDLjava/lang/Object;)Z

...and so forth.

At the source level, java.dyn.InvokeDynamic appears to have an infinity of named static methods, each fully signature-polymorphic.

Similarly, the two methods named "invokeExact" and "invokeGeneric" in java.dyn.MethodHandle are also signature-polymorphic:

	myMH.<void>invokeExact();
	myMH.<String>invokeGeneric('c');

Calls to those methods compile to ordinary looking invokevirtual instructions, but with arbitrary signatures:

	invokevirtual java/dyn/MethodHandle, invokeExact, ()V
	invokevirtual java/dyn/MethodHandle, invokeGeneric, (C)Ljava/lang/String;

The latest new 292 feature affecting code generation is "ldc" of method handles and method types.  For source code examples, see this file:

	test/tools/javac/meth/MHLiterals.java

in this patch:

	http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/meth-ldc.patch

Finally, watch out for incompatible changes on the way.  We are downsizing CallSite, which is an incompatible change.  For updated use of CallSite, see examples such as this one (which turn out to be simpler):

	http://hg.openjdk.java.net/mlvm/mlvm/file/tip/netbeans/indy-demo/src/PrintArgsDemo.java

-- John

From szegedia at gmail.com  Thu Mar 25 01:16:26 2010
From: szegedia at gmail.com (Attila Szegedi)
Date: Thu, 25 Mar 2010 09:16:26 +0100
Subject: Duby dynamic dispatch has landed!
In-Reply-To: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com>
References: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com>
Message-ID: <2355438E-D61C-4D5B-9F30-E34F3869ADA1@gmail.com>

On 2010.03.25., at 3:17, Charles Oliver Nutter wrote:

> For Attila: I had to remove a spreadArguments handle you used for
> re-binding the method...not sure why. Here's the diff:
> 
> Index: src/org/dynalang/dynalink/support/DynamicLinkerImpl.java
> ===================================================================
> --- src/org/dynalang/dynalink/support/DynamicLinkerImpl.java	(revision 232)
> +++ src/org/dynalang/dynalink/support/DynamicLinkerImpl.java	(working copy)
> @@ -115,8 +115,6 @@
>         final MethodType genericType = invocation.type().generic();
>         final MethodHandle genericizedInvocation =
>             MethodHandles.convertArguments(invocation, genericType);
> -        final MethodHandle spreadInvocation = MethodHandles.spreadArguments(
> -                genericizedInvocation, SPREAD_GENERIC_INVOCATION);
> -        return MethodHandles.invoke(spreadInvocation, arguments);
> +        return MethodHandles.invoke(genericizedInvocation, arguments);
>     }
> }
> 
> I committed a built version with this hack...no tests, etc yet for
> Duby's "dynamic" type, but that will come soon.

That's odd. "arguments" is Object[]; spreadArguments is required to unpack these arguments and pass them on to the invoked method. 

The dynalang-invoke's own test suites fail quite massively when I make the change, and work without the change (well, sans a bunch of TestSimpleDynamicMethod#testVarArgs...() tests which fail due to a MLVM bug, but that's in unrelated code for vararg method handling). I do only have my last august's version of MLVM though; I might need to re-run the tests with a new MLVM, although, honestly, I'd be surprised if that changed anything since to me, the logic seems okay.

Attila.

--
home: http://www.szegedi.org
twitter: http://twitter.com/szegedi
weblog: http://constc.blogspot.com






From john.rose at sun.com  Thu Mar 25 03:25:01 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Thu, 25 Mar 2010 10:25:01 +0000
Subject: hg: mlvm/mlvm/jdk: indy: improve javadoc;
	add temporary backward compatibility logic for CallSite
Message-ID: <20100325102501.DA3A344292@hg.openjdk.java.net>

Changeset: 8b0a03b04092
Author:    jrose
Date:      2010-03-25 03:24 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/8b0a03b04092

indy: improve javadoc; add temporary backward compatibility logic for CallSite

! meth-ing.patch


From John.Rose at Sun.COM  Thu Mar 25 03:29:59 2010
From: John.Rose at Sun.COM (John Rose)
Date: Thu, 25 Mar 2010 03:29:59 -0700
Subject: JSR 292 RI status & javadoc checkpoint
Message-ID: <4745D5A8-B7CC-407B-AD3C-29BDFD2765C5@sun.com>

The JSR 292 EG has been working with me to refine and clarify the spec for invokedynamic.  I have pushed updates to the RI to reflect this ongoing work.  For the record, here is javadoc for the current state of the RI:

  http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/

The presentation and logic of the javadoc is not perfect.  Please do send me your suggestions for improvement!

Here are some holes in the implementation that I know about and will fix soon:

- translation from signatures to method types sometimes fails on classes not on the boot class path

- java.dyn.MethodHandle inherits from a type MethodHandleImpl that needs to go away

- adapter method handles cannot be built for some signatures, including those for which primitives precede references

- MH.invokeGeneric behaves the same as MH.invokeExact (oops: it is supposed to be more permissive)

Best wishes,
-- John

From forax at univ-mlv.fr  Thu Mar 25 08:12:20 2010
From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=)
Date: Thu, 25 Mar 2010 16:12:20 +0100
Subject: Duby dynamic dispatch has landed!
In-Reply-To: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com>
References: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com>
Message-ID: <4BAB7D54.6020207@univ-mlv.fr>

Le 25/03/2010 03:17, Charles Oliver Nutter a ?crit :
> I love Duby sometimes, I really do.
>
> I've just landed full dynamic dispatch support. Here's an example
> script and session:
>
> ~/projects/duby ? cat examples/dynamic.duby
> # Example of using a dynamic type in a method definition
> def foo(a:dynamic)
>    puts "I got a #{a.getClass.getName} of size #{a.size}"
> end
>
> class SizeThing
>    def initialize(size:int)
>      @size = size
>    end
>
>    def size
>      @size
>    end
> end
>
> foo([1,2,3])
> foo(SizeThing.new(12))
>
> ~/projects/duby ? bin/duby examples/dynamic.duby
> I got a java.util.Collections$UnmodifiableRandomAccessList of size 3
> I got a examples.SizeThing of size 12
>
> I like this example because it's two totally disjoint types that
> happen to both have a "size" method, and Duby + indy + dynalang
> handles them just fine.
>
> So far I'm doing it like C#, specifying a "dynamic" type that
> propagates as-is through the type inference phase(s), but for bytecode
> and signature generation it gets erased to java.lang.Object.
>    

I've also found useful to propagate expected type back to the calling 
method.
Example:
if (foo()) { ... }

should be translated to indy foo ()Z instead of ()Object because if () 
wait for a boolean.

> - Charlie
>    

R?mi

From headius at headius.com  Thu Mar 25 10:13:05 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Thu, 25 Mar 2010 12:13:05 -0500
Subject: Duby dynamic dispatch has landed!
In-Reply-To: <4BAB7D54.6020207@univ-mlv.fr>
References: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com> 
	<4BAB7D54.6020207@univ-mlv.fr>
Message-ID: <f04d2211003251013j604bd30bre44e6edf5e74f920@mail.gmail.com>

On Thu, Mar 25, 2010 at 10:12 AM, R?mi Forax <forax at univ-mlv.fr> wrote:
> I've also found useful to propagate expected type back to the calling
> method.
> Example:
> if (foo()) { ... }
>
> should be translated to indy foo ()Z instead of ()Object because if ()
> wait for a boolean.

Yeah, I suppose this is appropriate for any "call" that is seen to be
receiving a dynamic type, i.e.:

def foo(a:List, b:dynamic)
  a.get(b.size) # size should be indy size()I

I'll have to see what I'd need to do in Duby's type engine to have
"upstream" type requirements influence "downstream" inferred types.

- Charlie

From szegedia at gmail.com  Thu Mar 25 10:18:27 2010
From: szegedia at gmail.com (Attila Szegedi)
Date: Thu, 25 Mar 2010 18:18:27 +0100
Subject: Duby dynamic dispatch has landed!
In-Reply-To: <f04d2211003251013j604bd30bre44e6edf5e74f920@mail.gmail.com>
References: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com>
	<4BAB7D54.6020207@univ-mlv.fr>
	<f04d2211003251013j604bd30bre44e6edf5e74f920@mail.gmail.com>
Message-ID: <F1FA6864-C16D-4D26-8201-1F715F4D8A41@gmail.com>

Also worth noting is that if you specify a specific return type (i.e. boolean) at the call site, MOP will ensure that whatever method ends up invoked, the return value is converted (either using built-in JVM conversions, or even your own language-specific ones if you provide a GuardingTypeConverterFactory implementation).

Attila.

On 2010.03.25., at 18:13, Charles Oliver Nutter wrote:

> On Thu, Mar 25, 2010 at 10:12 AM, R?mi Forax <forax at univ-mlv.fr> wrote:
>> I've also found useful to propagate expected type back to the calling
>> method.
>> Example:
>> if (foo()) { ... }
>> 
>> should be translated to indy foo ()Z instead of ()Object because if ()
>> wait for a boolean.
> 
> Yeah, I suppose this is appropriate for any "call" that is seen to be
> receiving a dynamic type, i.e.:
> 
> def foo(a:List, b:dynamic)
>  a.get(b.size) # size should be indy size()I
> 
> I'll have to see what I'd need to do in Duby's type engine to have
> "upstream" type requirements influence "downstream" inferred types.
> 
> - Charlie

From headius at headius.com  Thu Mar 25 10:33:22 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Thu, 25 Mar 2010 12:33:22 -0500
Subject: Duby dynamic dispatch has landed!
In-Reply-To: <2355438E-D61C-4D5B-9F30-E34F3869ADA1@gmail.com>
References: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com> 
	<2355438E-D61C-4D5B-9F30-E34F3869ADA1@gmail.com>
Message-ID: <f04d2211003251033s1d459aaek975a2481833e2f2d@mail.gmail.com>

On Thu, Mar 25, 2010 at 3:16 AM, Attila Szegedi <szegedia at gmail.com> wrote:
> That's odd. "arguments" is Object[]; spreadArguments is required to unpack these arguments and pass them on to the invoked method.
>
> The dynalang-invoke's own test suites fail quite massively when I make the change, and work without the change (well, sans a bunch of TestSimpleDynamicMethod#testVarArgs...() tests which fail due to a MLVM bug, but that's in unrelated code for vararg method handling). I do only have my last august's version of MLVM though; I might need to re-run the tests with a new MLVM, although, honestly, I'd be surprised if that changed anything since to me, the logic seems okay.

FWIW, here's the error I was getting. I haven't dug into it much other
than to remove spreadArguments:

MethodHandleImpl.java:1104:in `raiseException':
java.lang.ClassCastException: required class [Ljava.lang.Object; but
encountered class java.util.Collections$UnmodifiableRandomAccessList
	from MethodHandle.java:357:in `invokeVarargs'
	from MethodHandles.java:563:in `invoke'
	from DynamicLinkerImpl.java:120:in `_relinkAndInvoke'
	from FilterGeneric.java:520:in `invoke_C0'
	from dynamic.duby:3:in `foo'
...

If you want to give it a shot you just need a JRuby snapshot build
(ci.jruby.org/snapshots), BiteScript (github.com/headius/bitescript),
and Duby (github.com/headius.duby). I committed my patched
dynalang-invoke jar in Duby's javalib dir. javac
src/org/jruby/duby/DynalangBootstrap.java and run jruby bin/duby <file
or -e> with appropriate JAVA_OPTS for invokedynamic.

Speaking of that...I was surprised there's no baseline bootstrap
method built into dynalang/invoke. It was a trivial amount of code to
write, but I can imagine a lot of simple uses of dynalang/invoke will
just want to use the standard multimethod Java dispatch directly. If I
put together a patch to include my DynalangBootstrap.java, will you
accept it? (or maybe I have commit rights and I don't know it?)

P.S. Switch to git :)

- Charlie

From John.Rose at Sun.COM  Thu Mar 25 10:47:49 2010
From: John.Rose at Sun.COM (John Rose)
Date: Thu, 25 Mar 2010 10:47:49 -0700
Subject: Duby dynamic dispatch has landed!
In-Reply-To: <4BAB7D54.6020207@univ-mlv.fr>
References: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com>
	<4BAB7D54.6020207@univ-mlv.fr>
Message-ID: <DFDEBDD6-A3CC-4F1D-9469-559A1921DE4E@sun.com>

On Mar 25, 2010, at 8:12 AM, R?mi Forax wrote:

> I've also found useful to propagate expected type back to the calling 
> method.
> Example:
> if (foo()) { ... }
> 
> should be translated to indy foo ()Z instead of ()Object because if () 
> wait for a boolean.

Besides booleans, this is probably most useful for the return type void.  It's easy for a MH adapter to drop a value, but harder to create one from a void method.  So there's a likely performance benefit from declaring that you don't care about the return value.

-- John

From forax at univ-mlv.fr  Thu Mar 25 11:02:23 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 25 Mar 2010 19:02:23 +0100
Subject: Backport update
In-Reply-To: <254BBAAC-79AE-4327-A2FD-5850814F0944@sun.com>
References: <254BBAAC-79AE-4327-A2FD-5850814F0944@sun.com>
Message-ID: <4BABA52F.5020209@univ-mlv.fr>

I've updated the backport (1.3) to be in sync with the current mlvm status.
http://code.google.com/p/jvm-language-runtime/downloads/list

It supports lightweight CallSite, invokeExact, invokeGeneric but
the support of new ldc is not ready (I need a new version of ASM
and currently some regression tests failed).

invokeGeneric does a real invokeGeneric or at least I think it does :)
invokeExact is an alias for invokeGeneric.

R?mi


Le 25/03/2010 03:03, John Rose a ?crit :
> The JSR 292 EG has decided to simplify some aspects of the API.  I have just pushed updated patches to mlvm which embody these changes.
>
> CallSite is more streamlined.  The only field it has is the target method handle.  The caller class, type, and name have gone away.    It is simple to create a CallSite subclass that remembers this information if you need it.  Here's an example usage:
>    http://hg.openjdk.java.net/mlvm/mlvm/file/1c7351d7192f/netbeans/indy-demo/src/GetNameDemo.java
>
> Also, ldc of method handle constants is now supported.  There is a patch in langtools with a prototype syntax to support this at the source level.
>
> Note:  The updated patches to hotspot are untested on x86/64 and SPARC systems.
>
> -- John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>    


From szegedia at gmail.com  Thu Mar 25 10:56:16 2010
From: szegedia at gmail.com (Attila Szegedi)
Date: Thu, 25 Mar 2010 18:56:16 +0100
Subject: Duby dynamic dispatch has landed!
In-Reply-To: <f04d2211003251033s1d459aaek975a2481833e2f2d@mail.gmail.com>
References: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com>
	<2355438E-D61C-4D5B-9F30-E34F3869ADA1@gmail.com>
	<f04d2211003251033s1d459aaek975a2481833e2f2d@mail.gmail.com>
Message-ID: <032AC890-C37A-487F-93AF-EFCB67CE2782@gmail.com>

On 2010.03.25., at 18:33, Charles Oliver Nutter wrote:

> Speaking of that...I was surprised there's no baseline bootstrap
> method built into dynalang/invoke. It was a trivial amount of code to
> write, but I can imagine a lot of simple uses of dynalang/invoke will
> just want to use the standard multimethod Java dispatch directly. If I
> put together a patch to include my DynalangBootstrap.java, will you
> accept it? (or maybe I have commit rights and I don't know it?)

I did give tips for usage in DynamicLinker javadoc; the simplest you can get is:

public class MyLanguageRuntime {
    private static final DynamicLinker dynamicLinker = new DynamicLinkerFactory().createLinker();
    
    public static CallSite bootstrap(Object caller, String name, MethodType type) {
        RelinkableCallSite callSite = new MonomorphicCallSite(caller, name, type);
        dynamicLinker.link(callSite);
        return callSite;
    }
}

and then every class just does:

public class MyClass {
    static {
        Linkage.registerBootstrapMethod(MyLanguageRuntime.class, "bootstrap");
    }
    ...
}

> P.S. Switch to git :)

I will; I certainly have the intent. I do have an account on github, I created it to fork Syrinx last year to integrate it with MOP :-) I'm still learning it (Git, that is). As I lamented elsewhere: first I encountered CVS[*]. By the time I mastered CVS, Subversion comes along. By the time I decently learned Subversion, I need Mercurial (for MLVM). By the time I grasp enough Mercurial to check out OpenJDK and apply MLVM patches, cool kids go Git. It's hard keeping up with the version control system fashion... :-)

What (if any) IDE integration do you use with Git?

Attila.

[*] Actually, first was SourceSafe, but I prefer to forget mentioning that.

> 
> - Charlie

From John.Rose at Sun.COM  Thu Mar 25 11:14:53 2010
From: John.Rose at Sun.COM (John Rose)
Date: Thu, 25 Mar 2010 11:14:53 -0700
Subject: Duby dynamic dispatch has landed!
In-Reply-To: <f04d2211003251033s1d459aaek975a2481833e2f2d@mail.gmail.com>
References: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com>
	<2355438E-D61C-4D5B-9F30-E34F3869ADA1@gmail.com>
	<f04d2211003251033s1d459aaek975a2481833e2f2d@mail.gmail.com>
Message-ID: <F1915EEA-BE9E-455D-A336-985A3F7C5703@sun.com>

On Mar 25, 2010, at 10:33 AM, Charles Oliver Nutter wrote:

> On Thu, Mar 25, 2010 at 3:16 AM, Attila Szegedi <szegedia at gmail.com> wrote:
>> That's odd. "arguments" is Object[]; spreadArguments is required to unpack these arguments and pass them on to the invoked method.
>> 
>> The dynalang-invoke's own test suites fail quite massively when I make the change, and work without the change (well, sans a bunch of TestSimpleDynamicMethod#testVarArgs...() tests which fail due to a MLVM bug, but that's in unrelated code for vararg method handling). I do only have my last august's version of MLVM though; I might need to re-run the tests with a new MLVM, although, honestly, I'd be surprised if that changed anything since to me, the logic seems okay.
> 
> FWIW, here's the error I was getting. I haven't dug into it much other
> than to remove spreadArguments:
> 
> MethodHandleImpl.java:1104:in `raiseException':
> java.lang.ClassCastException: required class [Ljava.lang.Object; but
> encountered class java.util.Collections$UnmodifiableRandomAccessList
> 	from MethodHandle.java:357:in `invokeVarargs'
> 	from MethodHandles.java:563:in `invoke'
> 	from DynamicLinkerImpl.java:120:in `_relinkAndInvoke'
> 	from FilterGeneric.java:520:in `invoke_C0'
> 	from dynamic.duby:3:in `foo'
> ...

Do you know who is creating the UnmodifiableRandomAccessList?

It looks like it needs a toArray call to create the low-level varargs list.

(It would be nice if the MHs combinators dealt with lists, but they don't at present, at least not in a regular fashion.)

> If you want to give it a shot you just need a JRuby snapshot build
> (ci.jruby.org/snapshots), BiteScript (github.com/headius/bitescript),
> and Duby (github.com/headius.duby). I committed my patched
> dynalang-invoke jar in Duby's javalib dir. javac
> src/org/jruby/duby/DynalangBootstrap.java and run jruby bin/duby <file
> or -e> with appropriate JAVA_OPTS for invokedynamic.

I did some browsing and downloading, but there are too many moving parts to quickly figure out... Sorry!

> Speaking of that...I was surprised there's no baseline bootstrap
> method built into dynalang/invoke. It was a trivial amount of code to
> write, but I can imagine a lot of simple uses of dynalang/invoke will
> just want to use the standard multimethod Java dispatch directly. If I
> put together a patch to include my DynalangBootstrap.java, will you
> accept it? (or maybe I have commit rights and I don't know it?)

No, sorry, you don't at present, but you should have one.  However, to my surprise, you are not on this list, which is the first place your name needs to appear for such things:
  https://sca.dev.java.net/CA_signatories.htm

Send me link to DynalangBootstrap.java.  I browsed a couple obvious places under github.com/headius/duby but didn't see it.  (And there's no download page??)

> P.S. Switch to git :)

)-,;  ~~{ Oh foo, I just learned hg. }

-- John


From John.Rose at Sun.COM  Thu Mar 25 11:16:42 2010
From: John.Rose at Sun.COM (John Rose)
Date: Thu, 25 Mar 2010 11:16:42 -0700
Subject: Backport update
In-Reply-To: <4BABA52F.5020209@univ-mlv.fr>
References: <254BBAAC-79AE-4327-A2FD-5850814F0944@sun.com>
	<4BABA52F.5020209@univ-mlv.fr>
Message-ID: <6A4434FD-7395-4446-9FE7-97BBD42B7486@sun.com>

Amazing; congratulations!

On Mar 25, 2010, at 11:02 AM, R?mi Forax wrote:

> I've updated the backport (1.3) to be in sync with the current mlvm status.
> http://code.google.com/p/jvm-language-runtime/downloads/list
> 
> It supports lightweight CallSite, invokeExact, invokeGeneric but
> the support of new ldc is not ready (I need a new version of ASM
> and currently some regression tests failed).
> 
> invokeGeneric does a real invokeGeneric or at least I think it does :)
> invokeExact is an alias for invokeGeneric.

This is the exact opposite of the current state of the RI.

Use MH.invokeVarargs as a workaround, to get the most permissive behavior from both systems.

-- John

From headius at headius.com  Thu Mar 25 12:25:18 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Thu, 25 Mar 2010 14:25:18 -0500
Subject: Duby dynamic dispatch has landed!
In-Reply-To: <032AC890-C37A-487F-93AF-EFCB67CE2782@gmail.com>
References: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com> 
	<2355438E-D61C-4D5B-9F30-E34F3869ADA1@gmail.com>
	<f04d2211003251033s1d459aaek975a2481833e2f2d@mail.gmail.com> 
	<032AC890-C37A-487F-93AF-EFCB67CE2782@gmail.com>
Message-ID: <f04d2211003251225j700aacdar3910cea1d0cdae5@mail.gmail.com>

On Thu, Mar 25, 2010 at 12:56 PM, Attila Szegedi <szegedia at gmail.com> wrote:
> I did give tips for usage in DynamicLinker javadoc; the simplest you can get is:
>
> public class MyLanguageRuntime {
> ? ?private static final DynamicLinker dynamicLinker = new DynamicLinkerFactory().createLinker();
>
> ? ?public static CallSite bootstrap(Object caller, String name, MethodType type) {
> ? ? ? ?RelinkableCallSite callSite = new MonomorphicCallSite(caller, name, type);
> ? ? ? ?dynamicLinker.link(callSite);
> ? ? ? ?return callSite;
> ? ?}
> }
>
> and then every class just does:
>
> public class MyClass {
> ? ?static {
> ? ? ? ?Linkage.registerBootstrapMethod(MyLanguageRuntime.class, "bootstrap");
> ? ?}
> ? ?...
> }

Yep, that's exactly what I wanted. But I think it would be nice to
have a JavaLanguageLinker built-in so that I don't have to maintain
*any* Java code of my own. This is literally all I need, and I don't
think I'll be alone.

>> P.S. Switch to git :)
>
> I will; I certainly have the intent. I do have an account on github, I created it to fork Syrinx last year to integrate it with MOP :-) I'm still learning it (Git, that is). As I lamented elsewhere: first I encountered CVS[*]. By the time I mastered CVS, Subversion comes along. By the time I decently learned Subversion, I need Mercurial (for MLVM). By the time I grasp enough Mercurial to check out OpenJDK and apply MLVM patches, cool kids go Git. It's hard keeping up with the version control system fashion... :-)
>
> What (if any) IDE integration do you use with Git?

I've used CVS, SVN, SS, Hg, Git, Perforce (a little) and Clearcase (a
little). Git has just about the worst learning curve for cli
interaction, but it's structured better than any other I've used.

IDE support, unfortunately, lags enough that I don't use it. I have
use the nbgit plugin, which is pretty good. I'm pretty sure IDEA has
great integration as usual, and I've heard Eclipse is pretty good. I
just use command-line, raw git.

- Charlie

From headius at headius.com  Thu Mar 25 12:32:37 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Thu, 25 Mar 2010 14:32:37 -0500
Subject: Duby dynamic dispatch has landed!
In-Reply-To: <F1915EEA-BE9E-455D-A336-985A3F7C5703@sun.com>
References: <f04d2211003241917q67bc3300r6f4e7cf48da48cad@mail.gmail.com> 
	<2355438E-D61C-4D5B-9F30-E34F3869ADA1@gmail.com>
	<f04d2211003251033s1d459aaek975a2481833e2f2d@mail.gmail.com> 
	<F1915EEA-BE9E-455D-A336-985A3F7C5703@sun.com>
Message-ID: <f04d2211003251232x3bb29b5k3ae0c9e592f9a670@mail.gmail.com>

On Thu, Mar 25, 2010 at 1:14 PM, John Rose <John.Rose at sun.com> wrote:
>> MethodHandleImpl.java:1104:in `raiseException':
>> java.lang.ClassCastException: required class [Ljava.lang.Object; but
>> encountered class java.util.Collections$UnmodifiableRandomAccessList
>> ? ? ? from MethodHandle.java:357:in `invokeVarargs'
>> ? ? ? from MethodHandles.java:563:in `invoke'
>> ? ? ? from DynamicLinkerImpl.java:120:in `_relinkAndInvoke'
>> ? ? ? from FilterGeneric.java:520:in `invoke_C0'
>> ? ? ? from dynamic.duby:3:in `foo'
>> ...
>
> Do you know who is creating the UnmodifiableRandomAccessList?
>
> It looks like it needs a toArray call to create the low-level varargs list.

I don't think it does. The URAL comes from Duby's literal array syntax
(the [1,2,3] in the example) and for the error in question it's simply
the receiver of the call (getClass or size).

>> If you want to give it a shot you just need a JRuby snapshot build
>> (ci.jruby.org/snapshots), BiteScript (github.com/headius/bitescript),
>> and Duby (github.com/headius.duby). I committed my patched
>> dynalang-invoke jar in Duby's javalib dir. javac
>> src/org/jruby/duby/DynalangBootstrap.java and run jruby bin/duby <file
>> or -e> with appropriate JAVA_OPTS for invokedynamic.
>
> I did some browsing and downloading, but there are too many moving parts to quickly figure out... Sorry!

We'll have a release of Duby soon...then it will simply be:

1. install JRuby somehow (unpack, run installer, whatever)
2. gem install duby
3. duby <blah>

I'll let this list know when it's available that way.

>> Speaking of that...I was surprised there's no baseline bootstrap
>> method built into dynalang/invoke. It was a trivial amount of code to
>> write, but I can imagine a lot of simple uses of dynalang/invoke will
>> just want to use the standard multimethod Java dispatch directly. If I
>> put together a patch to include my DynalangBootstrap.java, will you
>> accept it? (or maybe I have commit rights and I don't know it?)
>
> No, sorry, you don't at present, but you should have one. ?However, to my surprise, you are not on this list, which is the first place your name needs to appear for such things:
> ?https://sca.dev.java.net/CA_signatories.htm
>
> Send me link to DynalangBootstrap.java. ?I browsed a couple obvious places under github.com/headius/duby but didn't see it. ?(And there's no download page??)

Actually I think this could just go into Attila's project, unless the
baseline dynalang Java MOP stuff could get included in JSR-292 (which
would be awesome, but I know that's a huge addition and it's too
late). I just figured that people interested in "plain old Java
dynamic dispatch" would want to just specify an existing bootstrap
method in Attila's library that only does Java multi-method dispatch.

In my ideal world, JSR-292 would ship with a default bootstrapper that
just does Java dispatch (with appropriate conversions for JLS dispatch
and maybe a minimal PIC) so that adding a "dynamic" type to Java
itself would basically be a done deal. Then Attila's MOP stuff would
just fall back on that dispatcher after trying language-specific ones.

- Charlie

From john.rose at sun.com  Sat Mar 27 02:48:12 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Sat, 27 Mar 2010 09:48:12 +0000
Subject: hg: mlvm/mlvm/hotspot: meth: fix unit tests;
	improve access checking logic
Message-ID: <20100327094812.EFCAD4458C@hg.openjdk.java.net>

Changeset: e6b2b7033950
Author:    jrose
Date:      2010-03-27 02:47 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/e6b2b7033950

meth: fix unit tests; improve access checking logic

! cpindex-cleanup.patch
! meth-ing.patch
! meth-ldc.patch


From john.rose at sun.com  Sat Mar 27 02:48:18 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Sat, 27 Mar 2010 09:48:18 +0000
Subject: hg: mlvm/mlvm/jdk: meth: fix unit tests; improve access checking logic
Message-ID: <20100327094818.6708B4458D@hg.openjdk.java.net>

Changeset: 8dbd8ecf725d
Author:    jrose
Date:      2010-03-27 02:47 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/8dbd8ecf725d

meth: fix unit tests; improve access checking logic

! meth-ing.patch


From john.rose at sun.com  Sat Mar 27 05:35:51 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Sat, 27 Mar 2010 12:35:51 +0000
Subject: hg: mlvm/mlvm/jdk: meth-bcp: fix problems with name resolution,
	so code need not be on the bootclasspath
Message-ID: <20100327123551.6243C445B6@hg.openjdk.java.net>

Changeset: ff2d7d3d25de
Author:    jrose
Date:      2010-03-27 05:35 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ff2d7d3d25de

meth-bcp: fix problems with name resolution, so code need not be on the bootclasspath

+ meth-bcp.patch
! meth-ing.patch
! series


From john.rose at sun.com  Sat Mar 27 05:35:51 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Sat, 27 Mar 2010 12:35:51 +0000
Subject: hg: mlvm/mlvm/hotspot: meth-bcp: fix problems with name resolution,
	so code need not be on the bootclasspath
Message-ID: <20100327123551.5F986445B5@hg.openjdk.java.net>

Changeset: 8c734933d83c
Author:    jrose
Date:      2010-03-27 05:35 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/8c734933d83c

meth-bcp: fix problems with name resolution, so code need not be on the bootclasspath

+ meth-bcp.patch
! series


From Christian.Thalinger at Sun.COM  Mon Mar 29 03:26:36 2010
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Mon, 29 Mar 2010 10:26:36 +0000
Subject: hg: mlvm/mlvm/hotspot: indy-sparc-6829193: A couple of fixes and
	changes.
Message-ID: <20100329102637.6BDAB44858@hg.openjdk.java.net>

Changeset: f06565654de2
Author:    twisti
Date:      2010-03-29 03:25 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f06565654de2

indy-sparc-6829193: A couple of fixes and changes.

! indy-sparc-6829193.patch


From forax at univ-mlv.fr  Mon Mar 29 03:30:17 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Mon, 29 Mar 2010 12:30:17 +0200
Subject: hg: mlvm/mlvm/hotspot: indy-sparc-6829193: A couple of fixes
	and	changes.
In-Reply-To: <20100329102637.6BDAB44858@hg.openjdk.java.net>
References: <20100329102637.6BDAB44858@hg.openjdk.java.net>
Message-ID: <4BB08139.1050803@univ-mlv.fr>

Le 29/03/2010 12:26, Christian.Thalinger at Sun.COM a ?crit :
> Changeset: f06565654de2
> Author:    twisti
> Date:      2010-03-29 03:25 -0700
> URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f06565654de2
>
> indy-sparc-6829193: A couple of fixes and changes.
>
> ! indy-sparc-6829193.patch
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>    

Thre is a in the middle of the patch :)

// TODO use below method when it's pushed.

R?mi





From Christian.Thalinger at Sun.COM  Mon Mar 29 03:32:58 2010
From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM)
Date: Mon, 29 Mar 2010 10:32:58 +0000
Subject: hg: mlvm/mlvm/hotspot: indy-sparc-6829193: Fixed x86 build.
Message-ID: <20100329103258.C4CE74485A@hg.openjdk.java.net>

Changeset: 78a0c933140f
Author:    twisti
Date:      2010-03-29 12:32 +0200
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/78a0c933140f

indy-sparc-6829193: Fixed x86 build.

! indy-sparc-6829193.patch


From Christian.Thalinger at Sun.COM  Mon Mar 29 04:14:18 2010
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Mon, 29 Mar 2010 13:14:18 +0200
Subject: hg: mlvm/mlvm/hotspot: indy-sparc-6829193: A couple of fixes and
	changes.
In-Reply-To: <4BB08139.1050803@univ-mlv.fr>
References: <20100329102637.6BDAB44858@hg.openjdk.java.net>
	<4BB08139.1050803@univ-mlv.fr>
Message-ID: <1269861258.10926.2.camel@macbook>

On Mon, 2010-03-29 at 12:30 +0200, R?mi Forax wrote:
> Thre is a in the middle of the patch :)
> 
> // TODO use below method when it's pushed.

I know.  It's already pushed to the hotspot repositories but hasn't been
merged yet to the bsd-port repository.  I will change that when it's
there.

-- Christian


From john.rose at sun.com  Mon Mar 29 17:42:44 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Tue, 30 Mar 2010 00:42:44 +0000
Subject: hg: mlvm/mlvm/jdk: coro: fix broken tag in series file
Message-ID: <20100330004245.7CDCB44934@hg.openjdk.java.net>

Changeset: 1b1545e84e06
Author:    jrose
Date:      2010-03-29 17:42 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/1b1545e84e06

coro: fix broken tag in series file

! series


From john.rose at sun.com  Mon Mar 29 17:47:47 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Tue, 30 Mar 2010 00:47:47 +0000
Subject: hg: mlvm/mlvm/hotspot: coro: add missing tag in series file
Message-ID: <20100330004747.F034844937@hg.openjdk.java.net>

Changeset: c8ea7b2a0a4a
Author:    jrose
Date:      2010-03-29 17:47 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/c8ea7b2a0a4a

coro: add missing tag in series file

! series


From john.rose at sun.com  Mon Mar 29 17:48:09 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Tue, 30 Mar 2010 00:48:09 +0000
Subject: hg: mlvm/mlvm/hotspot: meth,
	indy: incremental fixes for review of 6939134
Message-ID: <20100330004809.8B93F44938@hg.openjdk.java.net>

Changeset: 823ae5c903e3
Author:    jrose
Date:      2010-03-29 17:47 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/823ae5c903e3

meth, indy: incremental fixes for review of 6939134

! meth-ing.patch
! meth-ldc.patch


From john.rose at sun.com  Tue Mar 30 04:10:27 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Tue, 30 Mar 2010 11:10:27 +0000
Subject: hg: mlvm/mlvm/hotspot: meth: assign bug numbers for review
Message-ID: <20100330111028.CC65D449D6@hg.openjdk.java.net>

Changeset: 6a04d1f38ba4
Author:    jrose
Date:      2010-03-30 03:37 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/6a04d1f38ba4

meth: assign bug numbers for review

+ cpindex-6939207.patch
- cpindex-cleanup.patch
+ meth-bcp-6939196.patch
- meth-bcp.patch
+ meth-ing-6939134.patch
- meth-ing.patch
! meth-ldc-6939203.patch < meth-ldc.patch
! series


From john.rose at sun.com  Tue Mar 30 04:10:39 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Tue, 30 Mar 2010 11:10:39 +0000
Subject: hg: mlvm/mlvm/jdk: meth: assign bug numbers for review
Message-ID: <20100330111040.243FD449D7@hg.openjdk.java.net>

Changeset: 35f2af18a157
Author:    jrose
Date:      2010-03-30 03:36 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/35f2af18a157

meth: assign bug numbers for review

+ meth-bcp-6939196.patch
- meth-bcp.patch
+ meth-ing-6939134.patch
- meth-ing.patch
+ meth-ldc-6939203.patch
- meth-ldc.patch
! series


From john.rose at sun.com  Tue Mar 30 04:10:44 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Tue, 30 Mar 2010 11:10:44 +0000
Subject: hg: mlvm/mlvm/langtools: meth: assign bug numbers for review
Message-ID: <20100330111044.3F83B449D8@hg.openjdk.java.net>

Changeset: ab871ff01a91
Author:    jrose
Date:      2010-03-30 03:36 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/ab871ff01a91

meth: assign bug numbers for review

+ meth-ing-6939134.patch
- meth-ing.patch
= meth-ldc-6939203.patch < meth-ldc.patch
! series


From John.Rose at Sun.COM  Tue Mar 30 04:06:31 2010
From: John.Rose at Sun.COM (John Rose)
Date: Tue, 30 Mar 2010 04:06:31 -0700
Subject: Request for reviews (M): 6939196: method handle signatures off the
	boot class path get linkage errors
Message-ID: <C3CB1EDC-A1A5-431F-8737-0A3CF890E707@sun.com>

6939196: method handle signatures off the boot class path get linkage errors

http://cr.openjdk.java.net/~jrose/6939196/hs-webrev.00/
http://cr.openjdk.java.net/~jrose/6939196/jdk-webrev.00/

The bugtraq description is copied below.

- Adjust MethodType lookup logic to search off the BCP, but not to cache those results.
- Pass accessing class where it needs to be seen.
- A SignatureStream idiom "as_klass" for class lookup has been refactored.

Please review the JDK changes along with the JVM changes.  They are very simple:
- Remove workaround from MethodHandleImpl lookup code
- Add JUnit regression test to MethodHandlesTest

-- John

P.S.  Here is the description from bugtraq.

The following test program throws an error on the marked line.  The problem is a weakness in the current JSR 292 Reference Implementation logic for resolving MethodTypes that mention types not on the boot class path.

The workaround, therefore, is to load your entire JSR 292 application using -Xbootclasspath/a:myapp.jar.

import java.dyn.*;
import static java.dyn.MethodHandles.*;
import static java.dyn.MethodType.*;

public class BCPBug {
   // Local class which appears in method signature;
   static class Example { }
   static void bcpTypesOnly(Object x) { System.out.println("bcpTypesOnly"); }
   static void hasUserType(Example x) { System.out.println("hasUserType"); }

   public static void main(String... av) throws Throwable {
       Lookup lookup = lookup();
       MethodHandle bcpTypesOnly = lookup.findStatic(lookup.lookupClass(), "bcpTypesOnly", methodType(void.class, Object.class));
       MethodHandle hasUserType  = lookup.findStatic(lookup.lookupClass(), "hasUserType",  methodType(void.class, Example.class));

       bcpTypesOnly.<void>invokeExact((Object)null);
       hasUserType.<void>invokeExact((Example)null); // throws NoClassDefFoundError on BCPBug$Example
   }
}

/* Run:
$ $JAVA7X_HOME/bin/javac -d . BCPBug.java
$ $JAVA7X_HOME/bin/java -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles -cp . BCPBug
bcpTypesOnly
Exception in thread "main" java.lang.NoClassDefFoundError: BCPBug$Example
	at BCPBug.main(BCPBug.java:17)
*/


From John.Rose at Sun.COM  Tue Mar 30 04:24:47 2010
From: John.Rose at Sun.COM (John Rose)
Date: Tue, 30 Mar 2010 04:24:47 -0700
Subject: Request for reviews (L): 6939203: JSR 292 needs method handle
	constants
Message-ID: <FE0D0FDE-D1E1-4659-9C3F-120AE492565E@sun.com>

6939203: JSR 292 needs method handle constants
Summary: Add new CP types CONSTANT_MethodHandle, CONSTANT_MethodType; extend 'ldc' bytecode.
  http://cr.openjdk.java.net/~jrose/6939203/hs-webrev.00

Please review this small JDK change along with it:
  http://cr.openjdk.java.net/~jrose/6939203/jdk-webrev.00

In order to compile constant references to method handles and method types, the constant pool structure needs to be able to represent method handle references, and the ldc instruction updated (as it was for Class constants).

This feature completes the role of method handle as a lightweight but dynamic access point to any bytecode operation.  Without the ability to perform 'ldc', building a handle to a proposed bytecode level member access is 1-2 orders of magnitude more expensive, requiring a reflective lookup.

-- John

P.S. There is an experimental javac change which allows such constants to be written from within Java programs.  Here is the change set for reference:
  http://cr.openjdk.java.net/~jrose/6939203/lt-webrev.00

The test file for this change shows the sorts of method handle constants that can be formed:
  http://cr.openjdk.java.net/~jrose/6939203/lt-webrev.00/raw_files/new/test/tools/javac/meth/MHLiterals.java


From john.rose at sun.com  Wed Mar 31 12:35:50 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Wed, 31 Mar 2010 19:35:50 +0000
Subject: hg: mlvm/mlvm/hotspot: 2 new changesets
Message-ID: <20100331193551.6DBEE44BBC@hg.openjdk.java.net>

Changeset: 2a35db88e023
Author:    jrose
Date:      2010-03-31 12:35 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/2a35db88e023

meth: incorporate review comments

! meth-ing-6939134.patch

Changeset: f296bf13ef94
Author:    jrose
Date:      2010-03-31 12:35 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f296bf13ef94

meth: draft fix for conversion operation gaps

+ meth-conv-6939861.patch
! series


From john.rose at sun.com  Wed Mar 31 12:36:05 2010
From: john.rose at sun.com (john.rose at sun.com)
Date: Wed, 31 Mar 2010 19:36:05 +0000
Subject: hg: mlvm/mlvm/jdk: meth: draft fix for conversion operation gaps
Message-ID: <20100331193605.E497D44BBD@hg.openjdk.java.net>

Changeset: f70f45ed8267
Author:    jrose
Date:      2010-03-31 12:36 -0700
URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/f70f45ed8267

meth: draft fix for conversion operation gaps

+ meth-conv-6939861.patch
! series