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 <a...@redhat.com> wrote:
> 
> On 15/02/17 21:56, Christian Thalinger 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?
> 
> 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 via email to