Graal JVMCI Problem

Roland Schatz roland.schatz at oracle.com
Mon Jun 6 12:27:38 UTC 2016


On 06/06/2016 02:07 PM, Bahram Yarahmadi wrote:
> I entered -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI
> -XX:+UseJVMCICompiler -d64 -Djvmci.Compiler=graal as my vm default arg in
> eclipse but it didn't work
> then I tried this -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI
>   -d64 -Djvmci.Compiler=graal and it didn't work too
> I always get the same error which is :
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at BahramMain.<clinit>(BahramMain.java:26)
> Caused by: java.lang.UnsupportedOperationException: The VM does not support
> the JVMCI API.
> Currently used Java home directory is
> /home/bahram/graal/jvmci/jdk1.8.0_91/product/jre.
> Currently used VM configuration is: OpenJDK 64-Bit Server VM
> at jdk.vm.ci.runtime.JVMCI.getRuntime(JVMCI.java:50)
> at com.oracle.graal.api.test.Graal.initializeRuntime(Graal.java:44)
> at com.oracle.graal.api.test.Graal.<clinit>(Graal.java:40)
> ... 1 more

This looks like a classloader problem. Can you try running with the 
`-XX:-UseJVMCIClassLoader` option?

Since JVMCI is a security critical interface (you can basically do 
everything with it via installing bad code), normal application code can 
not access it. This is enforced with a special classloader. As a 
workaround you can disable this security mechanism with 
`-XX:-UseJVMCIClassLoader`. With this option, the JVMCI API is in the 
boot classpath and everyone is allowed to use it.

Note that this will change with JDK-9, where more fine-grained access 
control is available with the new module system.


- Roland

>
>
> Thanks again
>
> Regards
>
>
> On Mon, Jun 6, 2016 at 4:15 PM, Stefan Marr <java at stefan-marr.de> wrote:
>
>> Hi Bahram:
>>
>>
>>> On 06 Jun 2016, at 11:51, Bahram Yarahmadi <bahram.yarahmadi at gmail.com>
>> wrote:
>>> I tried to test all arguments that you mentioned but none of them worked
>>>   `mx -Mjit -v vm -version`  output on my computer is :
>>> /home/bahram/graal/jvmci/jdk1.8.0_91/product/bin/java -server
>> -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler
>> -d64 -Djvmci.Compiler=graal
>> -Xbootclasspath/p:/home/bahram/graal/truffle/mxbuild/dists/truffle-api.jar
>> -version
>>> openjdk version "1.8.0_91"
>>> OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14)
>>> OpenJDK 64-Bit Server VM (build 25.66-b00-internal-jvmci-0.9-dev, mixed
>> mode)
>>
>> Ok, so, that seems to be working correctly.
>>
>>> Since I don’t use truffle framework I changed it to graal-api.jar
>> location
>>
>> Ehm, I don’t think this is necessary. Just remove the
>> `-Xbootclasspath/p:/home/bahram/graal/truffle/mxbuild/dists/truffle-api.jar`
>> if you don’t want to use truffle. I’d assume that the rest works
>> automatically, without having to add any graal-specific jars.
>>
>>> I compiled it with mx --vm server build since 'mx build' does not ask me
>> which graal configuration I want to use anymore
>>> and since I want to use graal just for some special methods which I
>> specify I have to use graal in a hosted mode (server)
>>
>> With the latest changes, everything is built into the same binary. The
>> flags as above but excluding -XX:+UseJVMCICompiler correspond to the hosted
>> mode.
>>
>> Best regards
>> Stefan
>>
>>
>>
>>
>> --
>> Stefan Marr
>> Johannes Kepler Universität Linz
>> http://stefan-marr.de/research/
>>
>>
>>
>>



More information about the graal-dev mailing list