Re: Running jaotc with an external Graal

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Running jaotc with an external Graal

Doug Simon @ Oracle
I don’t know how one patches a module in the middle of the module graph. That is, we use --patch-module and --upgrade-module-path to override the jdk.vm.compiler module in the JDK. I don’t know what that means for modules such as jdk.aot that depend on jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help.

-Doug

> On 14 Feb 2017, at 12:26, Andrew Haley <[hidden email]> wrote:
>
> Is this possible?  Seems that no matter what I do, aotc always prefers to
> use the internal version of org.graalvm.compiler which is in HotSpot.
>
> I don't quite get why this is: I can run an external Graal using JVMCI
> with no problems.  I saw "8145337: [JVMCI] JVMCI initialization with
> SecurityManager installed fails:" which might be related, but perhaps
> it's not.
>
> So, why is it possible to use an external Graal with JVMCI, but
> apparently not with jaotc?  And is there anything I can do to make
> progress?
>
> Thanks,
>
> Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Running jaotc with an external Graal

Andrew Haley
On 14/02/17 13:34, Doug Simon wrote:

> I don’t know how one patches a module in the middle of the module
> graph. That is, we use --patch-module and --upgrade-module-path to
> override the jdk.vm.compiler module in the JDK. I don’t know what
> that means for modules such as jdk.aot that depend on
> jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help.

OK, thanks.  I guess I could try to upgrade the copy of Graal that is
contained in HotSpot.  I'll have a look.

Andrew.
Reply | Threaded
Open this post in threaded view
|

Re: Running jaotc with an external Graal

Alan Bateman
On 14/02/2017 14:20, Andrew Haley wrote:

> On 14/02/17 13:34, Doug Simon wrote:
>
>> I don’t know how one patches a module in the middle of the module
>> graph. That is, we use --patch-module and --upgrade-module-path to
>> override the jdk.vm.compiler module in the JDK. I don’t know what
>> that means for modules such as jdk.aot that depend on
>> jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help.
> OK, thanks.  I guess I could try to upgrade the copy of Graal that is
> contained in HotSpot.  I'll have a look.
>
>
--patch-module can be used to patch any module in the boot layer. So if
you are looking to override or add classes then --patch-module should work.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: Running jaotc with an external Graal

Andrew Haley
On 14/02/17 14:37, Alan Bateman wrote:
> --patch-module can be used to patch any module in the boot layer. So if
> you are looking to override or add classes then --patch-module should work.

Aha!  Thanks,

Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Running jaotc with an external Graal

Christian Thalinger-4

> On Feb 14, 2017, at 4:38 AM, Andrew Haley <[hidden email]> wrote:
>
> On 14/02/17 14:37, Alan Bateman wrote:
>> --patch-module can be used to patch any module in the boot layer. So if
>> you are looking to override or add classes then --patch-module should work.
>
> Aha!  Thanks,

Does it?
Reply | Threaded
Open this post in threaded view
|

Re: Running jaotc with an external Graal

Mandy Chung

> On Feb 15, 2017, at 1:56 PM, Christian Thalinger <[hidden email]> wrote:
>
>
>> On Feb 14, 2017, at 4:38 AM, Andrew Haley <[hidden email]> wrote:
>>
>> On 14/02/17 14:37, Alan Bateman wrote:
>>> --patch-module can be used to patch any module in the boot layer. So if
>>> you are looking to override or add classes then --patch-module should work.
>>
>> Aha!  Thanks,
>
> Does it?

Yes it does except that module-info.class can’t be patched.  You will get a warning if the patched path contains module-info.class.  Are you seeing the otherwise?

Mandy
Reply | Threaded
Open this post in threaded view
|

Re: Running jaotc with an external Graal

Remi Forax
Can i say again that when using --patch-module, module-info.class should be merged instead of having a warning ?

Rémi

----- Mail original -----
> De: "Mandy Chung" <[hidden email]>
> À: "Christian Thalinger" <[hidden email]>
> Cc: [hidden email], "hotspot compiler" <[hidden email]>, [hidden email]
> Envoyé: Mercredi 15 Février 2017 23:44:19
> Objet: Re: Running jaotc with an external Graal

>> On Feb 15, 2017, at 1:56 PM, Christian Thalinger <[hidden email]> wrote:
>>
>>
>>> On Feb 14, 2017, at 4:38 AM, Andrew Haley <[hidden email]> wrote:
>>>
>>> On 14/02/17 14:37, Alan Bateman wrote:
>>>> --patch-module can be used to patch any module in the boot layer. So if
>>>> you are looking to override or add classes then --patch-module should work.
>>>
>>> Aha!  Thanks,
>>
>> Does it?
>
> Yes it does except that module-info.class can’t be patched.  You will get a
> warning if the patched path contains module-info.class.  Are you seeing the
> otherwise?
>
> Mandy
Reply | Threaded
Open this post in threaded view
|

Re: Running jaotc with an external Graal

Andrew Haley
In reply to this post by Christian Thalinger-4
On 15/02/17 21:56, Christian Thalinger wrote:

>
>> On Feb 14, 2017, at 4:38 AM, Andrew Haley <[hidden email]> wrote:
>>
>> On 14/02/17 14:37, Alan Bateman wrote:
>>> --patch-module can be used to patch any module in the boot layer. So if
>>> you are looking to override or add classes then --patch-module should work.
>>
>> Aha!  Thanks,
>
> Does it?

Not quite.  The problem is that the service loader finds classes in
the Hotspot copy of Graal which don't exist in the external copy, and
chaos ensues.

I suppose the only way to make it work is to replace the copy of Graal
in HotSpot, but I don't think that's a trivial thing to do.

Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Running jaotc with an external Graal

Doug Simon @ Oracle
With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK:

java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar --upgrade-module-path=/Users/dsimon/hs/graal-core/mxbuild/modules/jdk.vm.compiler.jar --patch-module=jdk.vm.compiler=.jar -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version

However, the --patch-module + --upgrade-module-path trick[1] we’re using to replace the version of Graal in the JDK apparently only works due to a bug that will be fixed at some point. From Mandy Chung:

"-—patch-module is to patch a module to replace or add content of that module and yes it disables the hash checking on the patched module. However, it’s not intended to allow it to combine with —-upgrade-module-path as you did, to change the module dependences."

Given all the continuing flux around jigsaw, we cannot be sure that developing and using GitHub Graal on JDK 9 is stable until jigsaw is stable.

-Doug

[1] https://bugs.openjdk.java.net/browse/JDK-8171448?focusedCommentId=14046154&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14046154

> On 16 Feb 2017, at 10:17, Andrew Haley <[hidden email]> wrote:
>
> On 15/02/17 21:56, Christian Thalinger wrote:
>>
>>> On Feb 14, 2017, at 4:38 AM, Andrew Haley <[hidden email]> wrote:
>>>
>>> On 14/02/17 14:37, Alan Bateman wrote:
>>>> --patch-module can be used to patch any module in the boot layer. So if
>>>> you are looking to override or add classes then --patch-module should work.
>>>
>>> Aha!  Thanks,
>>
>> Does it?
>
> Not quite.  The problem is that the service loader finds classes in
> the Hotspot copy of Graal which don't exist in the external copy, and
> chaos ensues.
>
> I suppose the only way to make it work is to replace the copy of Graal
> in HotSpot, but I don't think that's a trivial thing to do.
>
> Andrew.
>

Reply | Threaded
Open this post in threaded view
|

Re: Running jaotc with an external Graal

Andrew Haley
On 16/02/17 09:33, Doug Simon wrote:
> With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK:
>
> java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar --upgrade-module-path=/Users/dsimon/hs/graal-core/mxbuild/modules/jdk.vm.compiler.jar --patch-module=jdk.vm.compiler=.jar -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version
>
> However, the --patch-module + --upgrade-module-path trick[1] we’re using to replace the version of Graal in the JDK apparently only works due to a bug that will be fixed at some point. From Mandy Chung:

Magic, thank you.  This works:

~/jdk10/hs/build/linux-aarch64-normal-server-release/jdk/bin/java \
-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI \
--add-exports=java.base/jdk.internal.module=jdk.vm.compiler \
--upgrade-module-path=/nfs/zebedee/home/graal/aph/graal-core/mxbuild/modules/jdk.vm.compiler.jar \
--patch-module=jdk.vm.compiler=.jar \
--module-path=/nfs/zebedee/home/graal/aph/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar:/nfs/zebedee/home/graal/aph/graal-core/mxbuild/modules/jdk.vm.compiler.jar \
-XX:+UseAOT -Djvmci.UseProfilingInformation=false \
-Dgraal.UseExceptionProbability=false -Djvmci.Compiler=graal \
--add-modules ALL-DEFAULT -m jdk.aot/jdk.tools.jaotc.Main ~/Hello.jar \
--output libHello.so

I'm posting it here for posterity.  It would indeed be very bad if we
could not do something at least equivalent to this.

Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Running jaotc with an external Graal

Mandy Chung
In reply to this post by Doug Simon @ Oracle

> On Feb 16, 2017, at 1:33 AM, Doug Simon <[hidden email]> wrote:
>
> With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK:
>
> java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar --upgrade-module-path=/Users/dsimon/hs/graal-core/mxbuild/modules/jdk.vm.compiler.jar --patch-module=jdk.vm.compiler=.jar -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version
>
> However, the --patch-module + --upgrade-module-path trick[1] we’re using to replace the version of Graal in the JDK apparently only works due to a bug that will be fixed at some point. From Mandy Chung:
>
> "-—patch-module is to patch a module to replace or add content of that module and yes it disables the hash checking on the patched module. However, it’s not intended to allow it to combine with —-upgrade-module-path as you did, to change the module dependences.”
>

It’s a bug that --patch-module + --upgrade-module-path work as described above.  I have a patch to fix —-patch-module that no longer has to disable the hash checking but allow patching the content of the mdoule.

I think we will need to look into the alternatives how Graal can be upgraded to a different version of module-info.class.

Mandy

> Given all the continuing flux around jigsaw, we cannot be sure that developing and using GitHub Graal on JDK 9 is stable until jigsaw is stable.
>
> -Doug
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8171448?focusedCommentId=14046154&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14046154
>
>> On 16 Feb 2017, at 10:17, Andrew Haley <[hidden email]> wrote:
>>
>> On 15/02/17 21:56, Christian Thalinger wrote:
>>>
>>>> On Feb 14, 2017, at 4:38 AM, Andrew Haley <[hidden email]> wrote:
>>>>
>>>> On 14/02/17 14:37, Alan Bateman wrote:
>>>>> --patch-module can be used to patch any module in the boot layer. So if
>>>>> you are looking to override or add classes then --patch-module should work.
>>>>
>>>> Aha!  Thanks,
>>>
>>> Does it?
>>
>> Not quite.  The problem is that the service loader finds classes in
>> the Hotspot copy of Graal which don't exist in the external copy, and
>> chaos ensues.
>>
>> I suppose the only way to make it work is to replace the copy of Graal
>> in HotSpot, but I don't think that's a trivial thing to do.
>>
>> Andrew.
>>
>