Re: Running jaotc with an external Graal

[Mandy Chung]

> On Feb 16, 2017, at 1:33 AM, 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:
> 
> "-—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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14046154
> 
>> On 16 Feb 2017, at 10:17, Andrew Haley  wrote:
>> 
>> On 15/02/17 21:56, Christian Thalinger wrote:
>>> 
 On Feb 14, 2017, at 4:38 AM, Andrew Haley  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.
>> 
> 

Re: Running jaotc with an external Graal

[Doug Simon]

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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14046154

> On 16 Feb 2017, at 10:17, Andrew Haley  wrote:
> 
> On 15/02/17 21:56, Christian Thalinger wrote:
>> 
>>> On Feb 14, 2017, at 4:38 AM, Andrew Haley  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.
> 

Re: Running jaotc with an external Graal

[Andrew Haley]

On 15/02/17 21:56, Christian Thalinger wrote:
> 
>> On Feb 14, 2017, at 4:38 AM, Andrew Haley  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.

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" <mandy.ch...@oracle.com>
> À: "Christian Thalinger" <cthalin...@twitter.com>
> Cc: jigsaw-dev@openjdk.java.net, "hotspot compiler" 
> <hotspot-compiler-...@openjdk.java.net>, graal-...@openjdk.java.net
> 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 <cthalin...@twitter.com> 
>> wrote:
>> 
>> 
>>> On Feb 14, 2017, at 4:38 AM, Andrew Haley <a...@redhat.com> 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

Re: Running jaotc with an external Graal

[Mandy Chung]

> On Feb 15, 2017, at 1:56 PM, Christian Thalinger  
> wrote:
> 
> 
>> On Feb 14, 2017, at 4:38 AM, Andrew Haley  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

Re: Running jaotc with an external Graal

[Christian Thalinger]

> On Feb 14, 2017, at 4:38 AM, Andrew Haley  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?

Re: Running jaotc with an external Graal

[Doug Simon]

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

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.

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

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.