In this series, I've been covering new developments of Shenandoah GC coming up in JDK 13. In part 1, I looked at the switch to load reference barriers, and, in part 2, I looked at plans for eliminating an extra word per object. In this article, I'll look at a new architecture and a new operating system that Shenandoah GC will be working with.
Solaris
BellSoft recently contributed a change that allowed Shenandoah to build and run on Solaris. Shenandoah itself has no operating system-specific code in it; therefore, it's relatively easy to port to new operating systems. In this case, it mostly amounts to a batch of fixes to make the Solaris compiler happy, like removing a trailing comma in enums.
One notable gotcha we encountered was with Solaris 10. Contrary to what later versions of Solaris do—and what basically all other relevant operating systems do—Solaris 10 maps user memory to upper address ranges (e.g., to addresses starting with 0xff... instead of 0x7f). Other operating systems reserve the upper half of the address space to kernel memory.
This approach conflicted with an optimization of Shenandoah's task queues, which would encode pointers assuming it has some spare space in the upper address range. It was easy enough to disable via build-time-flag, and Aleksey Shipilev did that. The fix is totally internal to Shenandoah GC and does not affect the representation of Java references in heap. With this change, Shenandoah can be built and run on Solaris 10 and newer (and possibly older, but we haven't tried). This is not only interesting for folks who want Shenandoah to run on Solaris, but also for us, because it requires the extra bit of cleanliness to make non-mainline toolchains happy.
The changes for Solaris support are already in JDK 13 development repositories and are already backported to Shenandoah's JDK 11 and JDK 8 backports repositories.
x86_32
Shenandoah used to support x86_32 in "passive" mode a long time ago. This mode relies only on stop-the-world GC to avoid implementing barriers (basically, it runs Degenerated GC all the time). It was an interesting mode to see the footprint numbers that you can get with uncommits and slimmer native pointers with really small microservice-size VMs. This mode was dropped before integration upstream, because many Shenandoah tests expect all heuristics/modes to work properly, and having the rudimentary x86_32 support was breaking tier1 tests. So, we disabled it.
Today, we have significantly simplified runtime interface thanks to load reference barriers and elimination of separate forwarding pointer slot, and we can build the fully concurrent x86_32 on top of that. This approach allows us to maintain 32-bit cleanness in Shenandoah code (we have fixed >5 bugs ahead of this change!), and it serves as proof of concept that Shenandoah can be implemented on 32-bit platforms. It is interesting in scenarios where the extra footprint savings are important, such as in containers or embedded systems. The combination of LRB + no more forwarding pointer + 32-bit support gives us the current lowest bounds for a footprint that would be possible with Shenandoah.
The changes for x86_32-bit support are done and ready to be integrated into JDK 13. However, they are currently waiting for the elimination of forwarding pointer change, which in turn is waiting for a nasty C2 bug fix. The plan is to later backport it to Shenandoah JDK 11 and JDK 8 backports, after the load reference barriers and elimination of forwarding pointer changes have been backported.
Other architectures and OSes
With those two additions to OS and architectures support, Shenandoah will soon be available (e.g., known to build and run) on four operating systems: Linux, Windows, MacOS, and Solaris, plus three architectures: x86_64, arm64 and x86_32. Given Shenandoah's design with zero OS-specific code, and not overly complex architecture-specific code, we may be looking at more operating systems or architectures to join the flock in future releases (if anybody finds it interesting enough to implement).
As always, if you don’t want to wait for releases, you can already have everything and help sort out problems: check out the Shenandoah GC Wiki.
Read more
Shenandoah GC in JDK 13, Part 1: Load reference barriers
Shenandoah GC in JDK 13, Part 2: Eliminating the forward pointer word
Last updated: June 27, 2019