Shenandoah GC in JDK 13, Part I: Load Reference Barriers

In this miniseries, I’d like to introduce a couple of new developments of the Shenandoah GC that are upcoming in JDK 13. Perhaps the most significant, even though not directly user-visible, change is the switch of Shenandoah’s barrier model to load reference barriers. It resolves one major point of criticism against Shenandoah, that is their expensive primitive read-barriers.

Shenandoah (as well as other collectors) employ barriers in order to ensure heap consistency. More specifically, Shenandoah GC employs barriers to ensure what we call ‘to-space-invariant’. What it means is this: when Shenandoah is collecting, it is copying objects from so-called ‘from-space’ to ‘to-space’, and it does so while Java threads are running (concurrently). This means that there may be two copies of any object floating around in the JVM. In order to maintain heap consistency, we need to ensure either of:

  • writes happen into to-space copy + reads can happen from both copies, subject to memory model constraints = weak to-space invariant

  • writes and reads always happen into/from the to-space copy = strong to-space invariant

And the way we ensure that is by employing the corresponding type of barriers whenever reads and writes happen. Consider this pseudocode:

void example(Foo foo) {
  Bar b1 =;             // Read
  while (..) {
    Baz baz = b1.baz;           // Read
    b1.x = makeSomeValue(baz);  // Write

Employing the Shenandoah barriers, it would look like this (what the JVM+GC would do under the hood):

void example(Foo foo) {
  Bar b1 = readBarrier(foo).bar;             // Read
  while (..) {
    Baz baz = readBarrier(b1).baz;           // Read
    X value = makeSomeValue(baz);
    writeBarrier(b1).x = readBarrier(value); // Write

I.e. whereever we read from an object, we first resolve the object via a read-barrier, and wherever we write to an object, we possibly copy the object to to-space. I won’t go into the details of this here, let’s just say that both operations are somewhat costly. Notice also that we need a read-barrier on the value of the write here to ensure we only ever write to-space-references into fields while heap references get updated (another nuisance of Shenandoah’s old barrier model).

Seeing that those barriers are a costly affair, we worked quite hard to optimize them. A very important optimization is to hoist barriers out of loops. We see that b1 is defined outside the loop, but only used inside the loop. We can just as well do the barriers outside the loop, once, instead of many times inside the loop:

void example(Foo foo) {
  Bar b1 = readBarrier(foo).bar;  // Read
  Bar b1' = readBarrier(b1);
  Bar b1'' = writeBarrier(b1);
  while (..) {
    Baz baz = b1'.baz;            // Read
    X value = makeSomeValue(baz);
    b1''.x = readBarrier(value);  // Write

And because write-barriers are stronger than read-barriers, we can fold the two up:

void example(Foo foo) {
  Bar b1 = readBarrier(foo).bar; // Read
  Bar b1' = writeBarrier(b1);
  while (..) {
    Baz baz = b1'.baz;           // Read
    X value = makeSomeValue(baz);
    b1'.x = readBarrier(value);  // Write

This is all nice and works fairly well, but it is also troublesome: the optimization passes for this are very complex. The fact that both from-space and two-space-copies of any objects can float around the JVM at any time is a major source of headaches and complexity. For example, we need extra barriers for comparing objects in case we compare an object to a different copy of itself. Read-barriers and write-barriers need to be inserted for *any* read or write, including primitive reads or writes. And those are very frequent, especially reads.

So why not short-cut this, and strongly ensure to-space-invariance right when an object is loaded from memory? That is where load-reference-barriers come in. They work mostly like our previous write-barriers, but are not employed at use-sites (when reading from or storing to the object), but instead much earlier when objects are loaded (at their definition-site):

void example(Foo foo) {
  Bar b1' = loadReferenceBarrier(;
  while (..) {
    Baz baz = loadReferenceBarrier(b1'.baz); // Read
    X value = makeSomeValue(baz);
    b1'.x = value;                           // Write

You can see that the code is basically the same as before – after our optimizations- , except that we didn’t need to optimize anything yet. Also, the read-barrier for the store-value is gone, because we now know (because of the strong to-space-invariant) that whatever makeSomeValue() did, it must already have employed the load-reference-barrier if needed. The new load-reference-barrier is almost 100% the same as our previous write-barrier.

The advantages of this barrier model are many (for us GC developers):

  • Strong invariant means it’s a lot easier to reason about the state of GC and objects
  • Much simpler barrier interface. Infact, a lot of stuff that we added to GC barrier interfaces after JDK11 will now become unused: no need for barriers on primitives, no need for object equality barriers, etc.
  • Optimization is much easier (see above). Barriers are naturally placed at the least-hot locations: their def-sites, instead of their most-hot locations: their use-sites, and then attempted to optimize them away from there (and not always successfully).
  • No more need for object equals barriers
  • No more need for ‘resolve’ barriers (a somewhat exotic kind of barriers used mostly in intrinsics and places that do read-like or write-like operations)
  • All barriers are now conditional, which opens up opportunities for further optimization later on
  • We can re-enable a bunch of optimizations like fast JNI getters that needed to be disabled before because they did not play well with possible from-space references

For users, this is mostly invisible, and the bottom line is that this improves overall Shenandoah’s performance. It also opens the way for follow-up improvements like elimination of the forwarding pointer, which I’ll get to in a follow-up article.

Load reference barriers have been integrated into JDK 13 development repository in April 2019. We will start backporting it to Shenandoah’s JDK 11 and JDK 8 backports soon. If you don’t want to wait, you can already have it: check out The Shenandoah GC Wiki.

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

7 Responses to Shenandoah GC in JDK 13, Part I: Load Reference Barriers

  1. Marco says:

    Wouldn’t the example for the new barrier scheme have to use loadReferenceBarrier(b1′.baz)?

    As far as I understand this, the barrier copies the object into to-space if not there yet, presumably in a shallow way. Bar’s primitive field values and its reference field addresses become directly available, baz may still sit in from-space though. The method example() doesn’t assume its parameter is in from space, neither would makeSomeValue(), so what copies baz when makeSomeValue() uses it?

    My expectation is that loadReferenceBarrier is required for all aaload and getfield(non-primitive) instructions, ignoring eliding optimizations?

    • Roman Kennke says:

      You are right, after loading baz it would have to go through the loadReferenceBarrier(…). Yes, this expectation is correct. Thank you!

      • Marco says:

        Thanks for clarifying.

        I really like how this plays with the bottleneck in my code, it doesn’t have any reference loads where it matters šŸ™‚

  2. Pingback: Shenandoah GC in JDK 13, Part II: Eliminating Forward Pointer Word | Roman Kennke's Blog

  3. Pingback: Shenandoah GC in JDK 13, Part III: Architectures and Operating Systems | Roman Kennke's Blog

  4. Peter says:

    What happens if a GC begins after the reference is loaded from memory? How do you maintain the strong to-space invariant then?

    • Roman Kennke says:

      Whenever we do a GC safepoint, we ensure that all roots are to-space afterwards. In particular, at the safepoint before starting evacuation, we evacuate and update all GC roots. That includes all currently in-use values in registers and stack.

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: