Shenandoah: A pauseless GC for OpenJDK

Update: It seems like this post gets frequently linked to, but is fairly old. For current information on Shenandoah GC, please refer to the Shenandoah Wiki.

It’s been quite a while that I did not post anything. The reason is that I was busy with a very interesting new project in the last weeks, Shenandoah, a new GC for OpenJDK. Christine, a collegue of mine in Red Hat’s Java team, set out to build a next generation garbage collector for OpenJDK. I jumped into this project a while ago, and I’m very excited about it.

I guess I will not go into technical details in this post, but instead outline a few of the problems of existing garbage collectors, and Shenandoah’s goals and some highlevel ideas how to achieve them.

  • Pause times: this problem existed since the invention of GCs, and hasn’t been fully solved since then. The good old stop-the-world garbage collection is probably still in everybody Java programmers mind. Nowadays we have more modern garbage collectors, and most of them drastically reduce pause times, but nevertheless, pause times still exist, be it for evacuation of regions, for book keeping of references, etc. Shenandoah aims to reduce pause times even more. Realistically speaking, there will still be pause times, but we aim to minimize them as much as possible. Our goal is to reduce them to less than 10ms per GC cycle.
  • Scalability. The larger the heap gets, and the more processors/threads are working, the more garbage is produced. This means more work for the garbage collector to find and free all this garbage. In other words, the garbage collector needs to be able to keep up with ever-growing memory demands and processor capability. We are shooting for TB-sized heaps.

The idea now is that, in order to reduce pause times, the GC needs to do as much work as possible concurrently to mutator threads (mutators are all threads that modify the heap, i.e. the actual application running). In order to be scalable, the GC needs to be able to utilize that ever-growing processing power by doing as much work as possible using multiple threads in parallel. (Notice that the terminology is a bit confusing here. In the Java GC world, ‘concurrent’ often means ‘concurrently with mutators’ while ‘parallel’ means ‘using parallel worker threads to do GC work’).

While that sounds conceptually simple, I can tell you it’s not. Boy, are there a lot of hairy issues to resolve here. I think I will explain the ideas one blog post at a time here. Stay tuned!

About Roman Kennke
JVM Hacker, Principal Software Engineer at Red Hat's OpenJDK team, Shenandoah GC project lead, Java Champion

15 Responses to Shenandoah: A pauseless GC for OpenJDK

  1. Alex says:

    Is this something similar to Azul’s C4 Garbage Collector?
    They claim 40 to 1000x the performance of the sun jvm:

  2. Roman Kennke says:

    Alex: Shenandoah a user level, software only solution. The first Azul collectors used hardware tag bits. The later collectors used Linux kernel level modifications.

  3. Alex says:

    That’s very interesting, I didn’t know that.
    So, openjdk could do that too?
    That would be completely awesome.

    • Gil Tene says:

      Cool stuff guys. Nice to have company. As in having someone embarking on taking this stuff on for real, instead of ignoring the problem or trying to convince the world that nobody needs more than 640KB (*10,000) in a single program…

      I’m happy to see that you have already overcome a key challenge: on the on the road of getting weened off of Stop-The-World GC, the biggest hurdle to overcome is denial. Like most recovery programs, the first step is acknowledging you have an actual problem. And your description makes it clear that you guys are not hiding your heads in the sand.

      There are many ways to skin this STW-GC problem (as evidenced by much academic works on the subject). Where can I find out more about Shenandoah?

      BTW, to set the record straight: C4 (in the form that has been shipping commercially inside our Zing JVM for a while now) is pure software, and it runs on vanilla, untouched Linux/x86 distros (RHEL 5.x/6.x, CentOS 5.x/6.x, SLES, Ubuntu, …) and the unmodified kernels that come with them.

      • Roman Kennke says:

        Gil: Eventually, this will become an OpenJDK project with code, mailing lists, wiki, etc. Until that happens (we’re working on it), I suppose the only source for information will be my blog. Thanks for the clarifications about C4, I did not know that. Does that mean you changed to a completely user level solution, or have the kernel hooks been integrated in all the mainline kernels? (In other words, is Zing/C4 – theoretically – able to run on a different OS, BSD, OSX, Windows, etc?)

  4. gustav says:

    When will you fix the static synchronized handling of native memory so it becomes scalable ?. Now you need to run multible VM:s to get a round it or replace the sucky design yourself.

    • Alex says:

      can you please explain the details of the problem you are referring to?
      I’m not aware of it and I would like to know more,

      • gustav says:

        Its the mechanism behind ByteBuffer.allocateDirect that provided statistics and limits the allocations. all with static synchronized logic.

  5. Michał Warecki says:

    Great Roman! Can you write something more about algorithms used in this GC (some basic assumptions)?

  6. pjmlp says:

    Maybe you should start by watching the presentations available about Azul in InfoQ?

  7. Roman, how can others get involved in the project?

  8. Jamsheed says:


    let me too know, i am too interested in contributing.

    Best Regards,

  9. Pingback: jClarity | Shenandoah – A new low pause Garbage Collection algorithm for the Java Hotspot JVM

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: