Graal JVMCI Problem

[Bahram Yarahmadi]

You are right ,It worked Ronald
I owe you too much and I can't thank you enough
Thank you all specially Stefan and Ronald

Regrads

On Mon, Jun 6, 2016 at 4:57 PM, Roland Schatz <roland.schatz at oracle.com>
wrote:

> 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/
>>>
>>>
>>>
>>>
>>>
>