Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for ZGC (garbage collector) #2149

Closed
brettwooldridge opened this issue Feb 13, 2020 · 19 comments
Closed

Support for ZGC (garbage collector) #2149

brettwooldridge opened this issue Feb 13, 2020 · 19 comments
Labels

Comments

@brettwooldridge
Copy link

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
Copy link

mk commented May 27, 2020

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
Copy link
Author

brettwooldridge commented May 28, 2020

@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
Copy link
Author

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

@dougxc
Copy link
Member

dougxc commented Nov 16, 2020

Tracked internally with GR-27475.

@Glavo
Copy link

Glavo commented Mar 16, 2021

What is the current state of the issue?

@dougxc
Copy link
Member

dougxc commented Mar 17, 2021

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

@brettwooldridge
Copy link
Author

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

@dougxc
Copy link
Member

dougxc commented May 8, 2021

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
Copy link
Contributor

rkennke commented May 8, 2021

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
Copy link
Member

dougxc commented May 8, 2021

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

@Glavo
Copy link

Glavo commented Jul 2, 2021

@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
Copy link

casperfrx commented Jul 3, 2021

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

@Glavo
Copy link

Glavo commented Jun 14, 2023

https://www.graalvm.org/release-notes/JDK_17/

Added support for the ZGC garbage collector for workloads that require low latency or use a very large heap size.

🎉

@liuchong
Copy link

https://www.graalvm.org/release-notes/JDK_17/

Added support for the ZGC garbage collector for workloads that require low latency or use a very large heap size.

🎉

That's great!

@toinouH
Copy link

toinouH commented Jun 15, 2023

I guess the issue isn't closed as Generational ZGC support is planned for the jdk21 build ?

@toinouH
Copy link

toinouH commented Sep 28, 2023

#6854 The issue was closed as marked as "done" but it seems unachived afaik ?
I wish I was wrong... I'm so hopeful for this.

@fniephaus
Copy link
Member

As some of you have pointed out, ZGC has landed in GraalVM for JDK 17+ (see #6170). We are tracking support for Generational ZGC in #8117.

@caoli5288
Copy link

As some of you have pointed out, ZGC has landed in GraalVM for JDK 17+ (see #6170). We are tracking support for Generational ZGC in #8117.

I see Setting EnableJVMCI to false as selected GC does not support JVMCI: z gc. Does this mean that the jit compiler will use c1 and c1?

@dougxc
Copy link
Member

dougxc commented Jun 30, 2024

I see Setting EnableJVMCI to false as selected GC does not support JVMCI: z gc. Does this mean that the jit compiler will use c1 and c1?

That is correct.

We hope to have Generational ZGC support in the GraalVM 24.1 release but if not, then it will almost certainly be in the GraalVM 24.2 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

10 participants