Support for ZGC (garbage collector)

[brettwooldridge]

ZGC Support

Is your feature request related to a problem? Please describe.
I work on a project where we have a monitoring system with very low tolerance for inaccurate/delayed measurement. That is not to say a real-time requirement, but delays we experienced under G1 exceeding 100ms where undesirable, and delays under G1 exceeding 1000ms extremely problematic.

ZGC has been our savior in this regard. We rarely see GC times above 2ms, and 99.9% less than 100ms.

We are currently on Java 11, and in some minor edges of the project we use Nashorn. Unfortunately, Nashorn has been deprecated and will disappear soon. GraalVM is the recommended path to continued support for JavaScript integration into Java.

Which leads to the conflict of needing GraalVM as well as ZGC in order to move off of Java 11. Luckily, Java 11 is LTS, but LTS does not mean forever.

Describe the solution you'd like.
Support for ZGC in GraalVM. In our case, we do not need native compilation support for ZGC, merely runtime support.

Describe who do you think will benefit the most.
Anyone using GraalVM in a high-speed transaction environment.

Describe alternatives you've considered.
Staying on Java 11, or switching Nashorn out for the last supported release of Rhino if we have to move to Java 17 LTS.

@bobmcwhirter @adinn I saw back last year your comments in #1278 regarding generating appropriate barriers for alternative GC to work. Basically this, I was told on the ZGC mailing list back in 2018, was the gating factor getting ZGC to work with GraalVM. Given that (maybe?) the barrier generation is there now, possibly ZGC is finally ready for integration and testing?

[mk]

We would also like to see support for ZGC in graal.

For the problem of Nashorn being deprecated however @brettwooldridge there's also the option to bring in graaljs as a library using a standard jdk by bringing in these two libraries:
https://mvnrepository.com/artifact/org.graalvm.js/js
https://mvnrepository.com/artifact/org.graalvm.js/js-scriptengine

[brettwooldridge]

@mk Thanks for the reply, I wasn't aware that the graalvm JavaScript support could be used "standalone" alongside the standard jdk. I guess it makes sense, but just didn't occur to me.

Of course, the ultimate goal of this request was so that we can use GraalVM across the board (for Java and JavaScript compilation) along with ZGC.

[brettwooldridge]

@bobmcwhirter @adinn Any thoughts on the priority of this, feasibility, or remaining hurdles (if any)?

[dougxc]

Tracked internally with GR-27475.

[Glavo]

What is the current state of the issue?

[dougxc]

Still on the to do list but no current activity. As always, external contributions are welcome.

[brettwooldridge]

@dougxc Same question, except now with respect to ShenandoahGC. We have switched from ZGC to Shenandoah for stability reasons.

[dougxc]

No change from the Graal team in terms of activity on this front at this time.
It might be worth checking with @rkennke if he or anyone else at RedHat is interested in adding ShenandoahGC support to Graal.

[rkennke]

I have an open WIP PR #2426, Dimitris Bakalios from the University of Crete (IIRC) is working on it, no ETA. Last time I heard of him it was running some workloads, but crashed on some others.

[dougxc]

Thanks @rkennke - that PR had fallen off my radar. Please ping me once it's ready for active review.

[Glavo]

@brettwooldridge

We are currently on Java 11, and in some minor edges of the project we use Nashorn. Unfortunately, Nashorn has been deprecated and will disappear soon. GraalVM is the recommended path to continued support for JavaScript integration into Java.

In fact, although nashorn is not part of JDK now, it is still maintained: openjdk/nashorn.

Nashorn 15.3 has just been released and now supports Java 17.

[casperfrx]

@brettwooldridge

We are currently on Java 11, and in some minor edges of the project we use Nashorn. Unfortunately, Nashorn has been deprecated and will disappear soon. GraalVM is the recommended path to continued support for JavaScript integration into Java.

In fact, although nashorn is not part of JDK now, it is still maintained: openjdk/nashorn.

Nashorn 15.3 has just been released and now supports Java 17.

Getting a little offtopic, but this is actually news to me and should definitely be updated on OpenJDK's JEP 372 page because it suggests no active maintenance is taking place on the Nashorn Engine:

The deprecation-for-removal of Nashorn in JDK 11 was confirmed in June 2018, causing the proposed removal to be flagged at every use of the jdk.nashorn.* API and the jjs tool in JDK 11, 12, and 13. During this period, no set of credible developers expressed a clear desire to maintain Nashorn in JDK 14 and beyond.