are there any invokedynamic enabled JVMs out there?
Jochen Theodorou
since I still have big trouble getting a working JVM with methodhandles
or at last invokedynamic I wonder if anyone has a precompiled one I
could use.
I could use one for Windows, or Linux. Both 32 bit of course, since the
64bit version is only in its beginning.
Can anyone help me out here?
bye Jochen
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
Rémi Forax
> Hi all,
>
> since I still have big trouble getting a working JVM with methodhandles
> or at last invokedynamic I wonder if anyone has a precompiled one I
> could use.
>
> I could use one for Windows, or Linux. Both 32 bit of course, since the
> 64bit version is only in its beginning.
>
> Can anyone help me out here?
>
> bye Jochen
>
>
Jochen, I perhaps understand why it doesn't work for you,
you don't need only the VM but also the java.dyn classes,
because the version given with jdk7 binaries is really outdated.
This means you have to compile the jdk too.
Rémi
Jochen Theodorou
[...]
> Jochen, I perhaps understand why it doesn't work for you,
> you don't need only the VM but also the java.dyn classes,
> because the version given with jdk7 binaries is really outdated.
>
> This means you have to compile the jdk too.
I think the problem is partially because it seems that the davinci build
just copies over files from an existing jdk. Before for example I had a
java version 7, but a javac version 6, because I did set the ALT_BOOTDIR
to a jdk6. For building the openjdk this is perfectly fine, but davinci
seems to make things different.
because of that problem I used a different jdk as boot, the openjdk. Now
I assume, that this gives problems with the BSD port who knows. Ok, so I
have to build the JDK too... but why doesn't the davinci build do that?
And how do I go forward from here? first build the patched BSD source
from and then the davinci part?
bye blackdrag
Rémi Forax
> Rémi Forax schrieb:
> [...]
>
>> Jochen, I perhaps understand why it doesn't work for you,
>> you don't need only the VM but also the java.dyn classes,
>> because the version given with jdk7 binaries is really outdated.
>>
>> This means you have to compile the jdk too.
>>
> I think the problem is partially because it seems that the davinci build
> just copies over files from an existing jdk. Before for example I had a
> java version 7, but a javac version 6, because I did set the ALT_BOOTDIR
> to a jdk6. For building the openjdk this is perfectly fine, but davinci
> seems to make things different.
>
> because of that problem I used a different jdk as boot, the openjdk. Now
> I assume, that this gives problems with the BSD port who knows. Ok, so I
> have to build the JDK too... but why doesn't the davinci build do that?
> And how do I go forward from here? first build the patched BSD source
> from and then the davinci part?
>
> bye blackdrag
>
>
Here is how I compile on linux 32bits:
- I first take the latest jdk binary build (b71)
- I set-up the davinci vm like describe here:
http://wikis.sun.com/display/mlvm/Building
- But at the end instead of using the makefile which never works for me :)
I use the shell commands described at the end of the README.txt
http://hg.openjdk.java.net/mlvm/mlvm/file/tip/README.txt
- and then in sources/hospot/make
ALT_BOOTDIR=path_to_jdk7_binaries; make
- After that, the VMs are
client:
hotspot/build/linux/export-linux-i586/jre/lib/i386/client
server:
hotspot/build/linux/export-linux-i586/jre/lib/i386/server
fastdebug-client:
hotspot/build/linux/export-linux-i586/fastdebug/jre/lib/i386/client
fastdebug-server:
hotspot/build/linux/export-linux-i586/fastdebug/jre/lib/i386/server
and copy the one that interrest me into path_to_jdk7/jre/lib/i386/
And change path_to_jdk7/jre/lib/i386/jvm.cfg to add them
-client IF_SERVER_CLASS -server
-server KNOWN
-davinci-client KNOWN
-davinci-server KNOWN
-debug-client KNOWN
-debug-server KNOWN
-hotspot ALIASED_TO -client
-classic WARN
-native ERROR
-green ERROR
- After that, I prepare a jar extracted from the jdk containing java.dyn
and sun.dyn,
like this, in davinci/sources/jdk/src/share/classes:
path_to_jdk7_binaries/bin/javac -J-Xmx1g -d /tmp/davinci_jsr292/
-sourcepath . java/dyn/*.java sun/dyn/*.java sun/dyn/*/*.java
and
cd /tmp/davinci_jsr292
jar cvfM ../jdk7-jsr292.jar java/dyn/* syn/dyn/*
Basically, I've now an uptodate JDK7 patched to add JSR292 API.
And to run the fidget example:
/usr/jdk/jdk1.7.0/bin/java -debug-server
-Xbootclasspath/p:/tmp/jdk7-jsr292.jar -XX:+UnlockExperimentalVMOptions
-XX:+EnableInvokeDynamic FidgetDemo
That's all, folks :)
Rémi
Jochen Theodorou
[...]
till here all works.
> - After that, I prepare a jar extracted from the jdk containing java.dyn
> and sun.dyn,
> like this, in davinci/sources/jdk/src/share/classes:
> path_to_jdk7_binaries/bin/javac -J-Xmx1g -d /tmp/davinci_jsr292/
> -sourcepath . java/dyn/*.java sun/dyn/*.java sun/dyn/*/*.java
> and
> cd /tmp/davinci_jsr292
> jar cvfM ../jdk7-jsr292.jar java/dyn/* syn/dyn/*
>
> Basically, I've now an uptodate JDK7 patched to add JSR292 API.
this does not work, a class is missing. But you gave me the jar, so I
can continue
> And to run the fidget example:
> /usr/jdk/jdk1.7.0/bin/java -debug-server
> -Xbootclasspath/p:/tmp/jdk7-jsr292.jar -XX:+UnlockExperimentalVMOptions
> -XX:+EnableInvokeDynamic FidgetDemo
>
> That's all, folks :)
I wish:
OpenJDK Server VM warning: JSR 292 method handle code is mismatched to
this JVM. Disabling support.
The FidgetDemo works with b71 out of the box, but with a newly compiled
hotspot it crashes with an internal error.
What is b71 itself capable of?
bye Jochen
Rémi Forax
Oups forget that. You need to include a linux/unix specific
implementation of a NIO2 class.
path_to_jdk7_binaries/bin/javac -J-Xmx1g -d /tmp/davinci_jsr292/
-sourcepath .:../../solaris/classes/ java/dyn/*.java sun/dyn/*.java sun/dyn/*/*.java
>
>> And to run the fidget example:
>> /usr/jdk/jdk1.7.0/bin/java -debug-server
>> -Xbootclasspath/p:/tmp/jdk7-jsr292.jar -XX:+UnlockExperimentalVMOptions
>> -XX:+EnableInvokeDynamic FidgetDemo
>>
>> That's all, folks :)
>>
> I wish:
>
> OpenJDK Server VM warning: JSR 292 method handle code is mismatched to
> this JVM. Disabling support.
>
hum, this means that you use a wrong VM or you don't patch the VM
sources has it should be.
> The FidgetDemo works with b71 out of the box, but with a newly compiled
> hotspot it crashes with an internal error.
>
> What is b71 itself capable of?
>
It supports only interpreter mode and all classes must be in the
bootstrap classpath.
> bye Jochen
cheers,
Rémi
Jochen Theodorou
[...]
>>> And to run the fidget example:
>>> /usr/jdk/jdk1.7.0/bin/java -debug-server
>>> -Xbootclasspath/p:/tmp/jdk7-jsr292.jar -XX:+UnlockExperimentalVMOptions
>>> -XX:+EnableInvokeDynamic FidgetDemo
>>>
>>> That's all, folks :)
>>>
>> I wish:
>>
>> OpenJDK Server VM warning: JSR 292 method handle code is mismatched to
>> this JVM. Disabling support.
>
> hum, this means that you use a wrong VM or you don't patch the VM
> sources has it should be.
it is the bootstrap VM from before. If it did not patch, then why does
it have a problem at all? Shouldn't the unpatched version work perfectly?
>> The FidgetDemo works with b71 out of the box, but with a newly compiled
>> hotspot it crashes with an internal error.
>>
>> What is b71 itself capable of?
>
> It supports only interpreter mode and all classes must be in the
> bootstrap classpath.
I don't care about the bootstrap classpath, but the interpreter mode is
a bit bad.