Can't run Graal with JDK 11
Doug Simon
doug.simon at oracle.com
Wed May 2 08:55:06 UTC 2018
Hi Andrew,
Sorry, I misunderstood that you were giving "mx vm" as an example of how you run jaotc.
The underlying problem here is that GitHub Graal contains packages such as org.graalvm.collections. Until recently, these classes were only used by Graal. However, they are now being used by Truffle which is not part of the Graal JDK module (and probably never will be). Furthermore, the Graal JDK module does not unqualified export these packages which means that Truffle apps on the class path cannot see them:
java.lang.IllegalAccessError: class com.oracle.truffle.api.frame.FrameDescriptor (in unnamed module @0x16e7dcfd) cannot access class org.graalvm.collections.EconomicMap (in module jdk.internal.vm.compiler) because module jdk.internal.vm.compiler does not export org.graalvm.collections to unnamed module @0x16e7dcfd
at com.oracle.truffle.api.frame.FrameDescriptor.<init>(FrameDescriptor.java:89)
at com.oracle.truffle.api.frame.FrameDescriptor.<init>(FrameDescriptor.java:76)
The solution adopted is to rename these "shared" packages when they are copied into OpenJDK Graal[1]. This now creates the problems you are seeing.
The last time we discussed this with the HotSpot compiler team, the proposal was to move jaotc into GitHub Graal and have the copy in OpenJDK be effectively read-only (like Graal currently is). I'm not sure of the status implementing this proposal - someone from the HotSpot compiler team should comment on that.
Until that's done, I agree that getting work done on jaotc will be challenging. The only workaround I can think of is to use the `mx updategraalinopenjdk` command as part of your workflow.
-Doug
[1] https://github.com/oracle/graal/blob/master/compiler/mx.compiler/mx_compiler.py#L1126
> On 2 May 2018, at 09:41, Andrew Haley <aph at redhat.com> wrote:
>
> On 05/01/2018 07:45 PM, Doug Simon wrote:
>> It sounds like you are somehow running jaotc via mx. I'm not sure how this is even possible. As you can see, it doesn't work.
>
> It worked until a few days ago. It's the only way I have to test aot.
> So this is a regression. Given that "it doesn't work", how is anyone
> supposed to get any work done?
>
>> If not, what mx command are you running to produce this error?
>
> Same as before:
>
> jaotc -J--module-path=/local/graal/graal/sdk/mxbuild/modules/org.graalvm.graal_sdk.jar:/local/graal/graal/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar:build/linux-aarch64-normal-server-slowdebug/jdk/modules/jdk.internal.vm.compiler \
> -J--upgrade-module-path=/local/graal/graal/compiler/mxbuild/modules/jdk.internal.vm.compiler.jar:/local/graal/graal/compiler/mxbuild/modules/jdk.internal.vm.compiler.management.jar
>
> But because of this recent refactoring it's no longer possible to to
> use --upgrade-module-path.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=k7FsjIingFVHhxqvJ9pQIiaQ2UoC3dxGJn-F-AJ9ddM&s=sv-IGtK5WXg2hORfLqHLKpx5IFbLT3qlaIYaZ3OCQOc&e=>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the hotspot-compiler-dev
mailing list