ASM 3.2
Rémi Forax
More on my blog :
http://weblogs.java.net/blog/forax/archive/2009/06/asm_now_support_1.html
Rémi
Guillaume Laforge
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Charles Oliver Nutter
this summer, and jruby nightlies will have it by monday! Thanks Remi
and ASM team!
Frank Wierzbicki
>
> Yesterday, asm 3.2 was released with full support of invokedynamic :)
-Frank
Charles Oliver Nutter
continue work from there :)
Jin
On Jun 12, 1:46 pm, Rémi Forax <fo...@univ-mlv.fr> wrote:
> Yesterday, asm 3.2 was released with full support of invokedynamic :)
>
>
> Rémi
Jochen Theodorou
> Yesterday, asm 3.2 was released with full support of invokedynamic :)
>
> More on my blog :
> http://weblogs.java.net/blog/forax/archive/2009/06/asm_now_support_1.html
Hi Rémi,
just tried out your example with jdk 1.7 b61. The compilation works and
the asm part too. But the actual MethodHandle part fails:
> [java] Exception in thread "main" java.lang.InternalError
> [java] at sun.dyn.MethodHandleNatives.init(Native Method)
> [java] at sun.dyn.DirectMethodHandle.<init>(DirectMethodHandle.java:48)
> [java] at sun.dyn.MethodHandleImpl.findMethod(MethodHandleImpl.java:163)
> [java] at java.dyn.MethodHandles$Lookup.findStatic(MethodHandles.java:202)
> [java] at java.dyn.Linkage.<clinit>(Linkage.java:200)
> [java] at Test.<clinit>(Test.java)
> [java] Java Result: 1
is b61 broken?
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
John Rose
has a number of implementation limits; this is probably one of them.
The example (not sure which you're trying) probably works in the mlvm
version. Here is a set of demos that are known to work:
http://hg.openjdk.java.net/mlvm/mlvm/file/tip/netbeans/indy-demo/src/
The currently passing unit tests are in:
http://hg.openjdk.java.net/mlvm/mlvm/file/tip/netbeans/meth/test
(See esp. meth/test/jdk/java/dyn/MethodHandlesTest.java.)
In general, as a "mere" matter of engineering process, a JVM built
from the mlvm patches will be a few weeks ahead of the JDK7 code.
-- John
Jochen Theodorou
> b61 has the same JVM bits as b59, the JavaOne preview release, which
> has a number of implementation limits; this is probably one of them.
the example is from
http://weblogs.java.net/blog/forax/archive/2009/06/asm_now_support_1.html
which I thought is working... ah well... the NYI I see in the log sounds
very much like a "not yet implemented" ;)
> The example (not sure which you're trying) probably works in the mlvm
> version. Here is a set of demos that are known to work:
> http://hg.openjdk.java.net/mlvm/mlvm/file/tip/netbeans/indy-demo/src/
known to work with mlvm or with openjdk7 b61? Because with b61 it seems
to not to work. There are several compilation errors I could fix, but
still I got the very same error. There is still no mlvm build I can
try... or even better, build myself.
> The currently passing unit tests are in:
> http://hg.openjdk.java.net/mlvm/mlvm/file/tip/netbeans/meth/test
>
> (See esp. meth/test/jdk/java/dyn/MethodHandlesTest.java.)
>
> In general, as a "mere" matter of engineering process, a JVM built
> from the mlvm patches will be a few weeks ahead of the JDK7 code.
well, the current b61 seems to be too basic to try anything.
bye Jochen
Rémi Forax
You can also try the backport,
source code is here :
http://code.google.com/p/jvm-language-runtime/source/browse/#svn/trunk/invokedynamic-backport
compile with ant
and run it (with jdk5+) like this :
java -javaagent:lib/jsr292-backport.jar MyMainClass
It retro-weaves 1.7 compatible classes to run on jdk5+ VM.
Currently you have to compile against latest classes found
in mlvm repo but I suppose I can provide a jar with empty skeletons
just to compile.
All method handle adapters are implemented but some of them
doesn't run at full speed (especially permute/spread/collect).
I've just commited changes to enable bound object to be JITed.
(a more convoluted patch than I want :)
cheers,
Rémi
Rémi Forax
I've created (extracted automatically from mlvm repository) a jar
containing the signature of all public methods of the classes
of the package java.dyn
So you can compile with this jar (you need a 1.7 javac):
javac -cp skeleton/jsr292-skeleton.jar:. -source 1.7 MyClass.java
run with the backport (1.5 and 1.6 or even 1.7 VM):
java -javaagent:lib/jsr292-backport.jar
This skeleton jar is also useful for me because it allows me to
do an automatic diff between the mlvm repo classes and the
backport ones.
Using this diff, I've discovered that I've forget to write
constructors of JavaMethodHandle that takes a String :)
cheers,
Rémi
Jochen Theodorou
[...]
> You can also try the backport,
> source code is here :
> http://code.google.com/p/jvm-language-runtime/source/browse/#svn/trunk/invokedynamic-backport
> compile with ant
> and run it (with jdk5+) like this :
>
> java -javaagent:lib/jsr292-backport.jar MyMainClass
>
> It retro-weaves 1.7 compatible classes to run on jdk5+ VM.
nice, but didn't John Rose kind of say such agents are purely evil?
Well, doesn't matter atm. What I wanted to test is how the stack is
shown if a call goes through a MethodHandle. That is for things like
Class.forName(String) for example. The backport won't help here if it is
normal java, since I then know that it will add additional stack frame
layers, that will influence what Class.forName will choose.
> Currently you have to compile against latest classes found
> in mlvm repo but I suppose I can provide a jar with empty skeletons
> just to compile.
>
> All method handle adapters are implemented but some of them
> doesn't run at full speed (especially permute/spread/collect).
>
> I've just commited changes to enable bound object to be JITed.
> (a more convoluted patch than I want :)
I think I should very soon have a very intense look at your code ;)
Rémi Forax
> Rémi Forax schrieb:
> [...]
>
>> You can also try the backport,
>> source code is here :
>> http://code.google.com/p/jvm-language-runtime/source/browse/#svn/trunk/invokedynamic-backport
>> compile with ant
>> and run it (with jdk5+) like this :
>>
>> java -javaagent:lib/jsr292-backport.jar MyMainClass
>>
>> It retro-weaves 1.7 compatible classes to run on jdk5+ VM.
>>
>
> nice, but didn't John Rose kind of say such agents are purely evil?
>
> Well, doesn't matter atm. What I wanted to test is how the stack is
> shown if a call goes through a MethodHandle.
If it's a methandle.invoke() or an invokedynamic you will not see it.
Other method adapters are like a standard method calls but some are
optimized
(like bound method handle) and doesn't appear in the stack trace.
> That is for things like
> Class.forName(String) for example. The backport won't help here if it is
> normal java, since I then know that it will add additional stack frame
> layers, that will influence what Class.forName will choose.
>
I don't clearly understand what is your problem.
MethodHandles are classes from java.dyn or sun.dyn and thus loaded by
the bootstrap classloader
so in my opinion, they will not have influence on Class.forName.
>
>> Currently you have to compile against latest classes found
>> in mlvm repo but I suppose I can provide a jar with empty skeletons
>> just to compile.
>>
>> All method handle adapters are implemented but some of them
>> doesn't run at full speed (especially permute/spread/collect).
>>
>> I've just commited changes to enable bound object to be JITed.
>> (a more convoluted patch than I want :)
>>
>
> I think I should very soon have a very intense look at your code ;)
>
> bye Jochen
>
>
cheers,
Rémi
-----------------------------------------------------------------------------------------------------------------------------*
Dr. Egon Spengler*: There's something very important I forgot to tell you.*
Dr. Peter Venkman*: What?*
Dr. Egon Spengler*: Don't cross the streams.*
Dr. Peter Venkman*: Why?*
Dr. Egon Spengler*: It would be bad.*
Dr. Peter Venkman*: I'm a little fuzzy on the whole "good/bad" thing
here. What do you mean, "bad"?*
Dr. Egon Spengler*: Try to imagine all life as you know it stopping
instantaneously and every molecule in your body exploding at the speed
of light.*
Dr. Ray Stantz*: Total protonic reversal!*
Dr. Peter Venkman*: That's bad. Okay. All right, important safety tip.
Thanks, Egon.
Jochen Theodorou
> Jochen Theodorou a écrit :
>> Rémi Forax schrieb:
[...]
> MethodHandles are classes from java.dyn or sun.dyn and thus loaded by
> the bootstrap classloader
> so in my opinion, they will not have influence on Class.forName.
in an environment where there is only one loader anyway, there is no
problem at all. But in case of running a groovy program from the command
line, the bootstrap loader contains almost nothing. Almost all libs are
loaded through a different loader and is below the bootstrap loader. So
if Class.forName selects the bootstrap loader you will have all kinds of
bad effects. Like for example a sql driver that cannot be found, but was
added at runtime by manipulating the runtime classpath. *Our* loader
then knows this one, but if Class.forName doesn't select it, it does not
help. And I am also thinking about java standard deserialization here.
That is very much fun with such a structure, especially since you have
to subclass ObjectInputStream to let it know your classloader.
so as long as Class#forName(String) does not select the classloader of
the caller class, because some reflective or other layers are in
between, it won't do.
bye blackdrag
Jochen Theodorou
> b61 has the same JVM bits as b59, the JavaOne preview release, which
> has a number of implementation limits; this is probably one of them.
> The example (not sure which you're trying) probably works in the mlvm
> version. Here is a set of demos that are known to work:
> http://hg.openjdk.java.net/mlvm/mlvm/file/tip/netbeans/indy-demo/src/
>
> The currently passing unit tests are in:
> http://hg.openjdk.java.net/mlvm/mlvm/file/tip/netbeans/meth/test
>
> (See esp. meth/test/jdk/java/dyn/MethodHandlesTest.java.)
>
> In general, as a "mere" matter of engineering process, a JVM built
> from the mlvm patches will be a few weeks ahead of the JDK7 code.
thanks to Chanwit's patches I finally managed to build the VM. But the
error is still the same. Either I did the build wrong in the end, or the
indy-demo is not working with the current version of mlvm.
bye Jochen