Graal: Java 11 support

[xbotuk]

As Java 8-10 will be obsolete very soon, GraalVM should support Java 11 also.

[dougxc]

We're working on this and aim to have it ready by the end of the year.

[renannprado]

@dougxc awesome news!

[Kindrat]

Any news, guys?

[dougxc]

We're continuing to make progress but it looks like it won't be ready as soon as I predicted.

[Kindrat]

Any ETA? Just for not to ping you too often.

[dougxc]

It's really hard to say but I think end of Feb 2019 is a safe bet.

[JAremko]

Java 11 seems really interesting for native-images since it has Epsilon GC that can be great option for short-lived CLI tools :scream_cat:

[olpaw]

@JAremko unfortunately that's not how it works. Epsilon GC is a JVM component that cannot be built into a native-image. All native images contain a special SVM GC implementation that's entirely written in Java (necessary requirement to bake it into a native image). //CC @Peter-B-Kessler

[JAremko]

@olpaw What a pity. :disappointed:
But thank you for clearing that up. :heart:

[mageddo]

Are you working only for java 11 support or java 12 it's also included for that release?

[christianwimmer]

We will support 11 and 12, and all future versions. There are only minor differences between 11 and 12, so that will not be much work.

[kaspernielsen]

What kind of support will there be for MethodHandles? direct method handlers only, or some way to store predefined non-direct method handles as well?

[abcfy2]

Any roadmap for this issue? Which version will support Java 11?
Thanks.

[dougxc]

There are a number of moving pieces in getting Java 11 support completed. This is work is being performed in parallel with continued development on Java 8. We want to get it out there as much as anyone else but it's just too hard to predict when it will be ready (as shown by my failed earlier attempt to do so). That said, we will not be shy about it when it is ready!

[lkwg82]

The question is, can you be transparent about how close you are?

[mikx]

Any update on this? Thanks!

[trnl]

Grateful if you can provide any ETA, at least in QQQs for 2019.

[bobmcwhirter]

@dougxc any branch or place we can experiment with the JDK11+ support, and contribute to help things along?

[dougxc]

There's no active branch of development apart from what's here on GitHub.

These are some of the larger pieces no one has spent time on yet:

• Implement Truffle and Graal isolation from the application in terms of module access control instead of class loaders. That is, use modules to do what we currently do with the JVMCI class loader (i.e. -XX:+UseJVMCIClassLoader).
• Modify the JDK 11 build system to build the jdk.internal.vm.compiler and jdk.internal.vm.compiler.management modules from GitHub Graal sources. This will be based on the updategraalinopenjdk script. In addition, the Truffle and GraalSDK modules also need to be added to the build.
• Figure out how to implement the graal-updater. It needs to add "components" to the GraalVM by modifying a JDK in-place. On JDK8 we do that with trusted directories (like the jre/ext mechanism). In JDK11+, there are at least these 2 possibilities:
  
  
  
  • Reproduce the JDK8 model and add trusted directories by programmatically loading modules and adding exports etc.
  
  
  • Use jlink to modify the JDK to add new modules and exports. I'm not sure this is possible given my rudimentary understanding of jlink where I believe it's primarily for deriving a new JDK image from an existing JDK image.
  
  

As stated, we will work on these as our focus shifts from 8 to 11 (or 13). Until then, contributions towards any of these tasks is very welcome.

[christianwimmer]

The current status for Native Image generation on JDK 11 is "something in the middle": you can build the source tree and build non-trivial native images with JDK 11. However, new Java APIs added after JDK 8 are only supported on a basic level. For example, we "support" the module system by always just returning the same singleton Module instance when you ask a class for its module.

As Doug said, all our our JDK 11 work is merged in master, there is no work that we have internally but not pushed out yet. Our current focus is more on stabilizing the JDK 8 support, but we welcome any external contributions that improve JDK 11 support.

[SchulteMarkus]

Thanks for updates, @dougxc and @christianwimmer

[Azbesciak]

Any update?

[pquiring]

In the mx build script for substratevm you can see references to JDK 11,13 and 14.
https://github.com/oracle/graal/blob/master/substratevm/mx.substratevm/mx_substratevm.py#L169
Not sure why JDK12 is not listed there so I added it to try and compile it, but still get other errors under Windows.
I would suspect that after JDK-13 is released we would see an updated version of GraalVM that targets it.

[pquiring]

19.3 will support Java 11 to be released in Oct.

https://www.infoworld.com/article/3439839/oracle-pits-graalvm-against-google-go.html

[cemo]

How about JDK13?

[thomaswue]

The article is off by 1 month, because 19.3 is scheduled for release on Nov-19 as shown at https://www.graalvm.org/docs/release-notes/version-roadmap/

We are discussing the possibility of also releasing a JDK-latest version (which would be JDK13 currently) in parallel, but it is unlikely to happen before early next year.

[matteobertozzi]

we had to go back from jdk11 to jdk8, because when using nashorn we discovered a memory leak (which is not fixed yet) https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8229011

I'll give it a try to see if graal.js and jdk11 suffer of the same problem

[thomaswue]

Graal.js does not dynamically generate bytecodes, so it is highly unlikely that it would be affected by this. In any case, let us know if it indeed is.

[cemo]

This can be closed @thomaswue :) Congrats!

PS: Is there a benchmark results?