Roman Kennke

Shenandoah GC landed in JDK12 about a year ago, giving OpenJDK another low-pause garbage collector. It has undergone substantial changes since then. Specifically we have a new barrier scheme, and have eliminated the extra forwarding pointer word per object, thus substantially reducing memory footprint. After giving a general introduction to OpenJDK GC landscape and Shenandoah GC, this talk focuses on those recent changes in Shenandoah and what's in it for you.

A new Garbage Collector interface has been introduced in OpenJDK 10, and has been further improved in OpenJDK 11 and 12. This talk will give a short sight-seeing tour through its design and its important interfaces and should give you an idea where to start, if you'd want to make your own Garbage Collector or want to get started with OpenJDKs existing collectors.

Much has happened in the last year for developers contributing to OpenJDK: - the repositories have been consolidated into a single repository - the run-test make target has been introduced - the JTReg (and jcov, asmtools and jtharness) build have been greatly improved - there is now a binary build of OpenJDK that can be used as --boot-jdk (on Linux x86-64)

The situation for HotSpot developers has also improved over the years: - the HotSpot build system was converted to the "new" build system - a proper unit test framework for C++ code (googletest) was added - debug symbols are no longer zipped by default - the JDK and HotSpot JTReg testlibraries were combined into one

This talk will show how all these changes make the OpenJDK developer experience a lot smoother. The speakers will also share their personal tips and tricks on how to work even faster on OpenJDK!

We also realize that the OpenJDK developer experience is far from optimal, and would therefore like this talk to initiate a discussion on what could be improved and how people can get involved.

Other people: Erik Helin

Garbage Collection (GC) liberates the programmer from having to call malloc and free. More importantly GC saves the programmer from having to debug their mistakes when using malloc and free. Unfortunately the details of how GC works are often a black box. This talk will start with a tour of all of the GC algorithms currently available in OpenJDK. We'll discuss how they work, their strengths and weaknesses, and which class of applications they were developed for. We'll work our way through serial gc, parallel gc, concurrent mark and sweep, and g1. We'll make the case for why we need all of them and just one more GC algorithm, Shenandoah.

Shenandoah is a parallel and concurrent GC algorithm designed for applications with 100gb+ heaps and tight pause time constraints. It's the first GC algorithm targeting OpenJDK which compacts the live objects while the Java threads are running. We'll describe the algorithm itself, the implementation details, and the optimizations needed to achieve good performance. We'll present performance numbers and give a demo that visualizes Shenandoah.

Other people: Christine H Flood

The Difference between Theory and Practice is greater in practice then it is in theory. We are on the brink of our first official release of Shenandoah. It took two weeks to write up the design and over two years to implement it. This talk will discuss the differences between what we initially proposed and what we now have working. An honest look at compromises, wrong turns, and innovations. We will finish the talk with the theory of what comes next: A high level design for NUMA aware GC, a sketch of a plan for truly pauseless GC, a brief consideration of reference counting...

Other people: Christine H Flood

Garbage Collection pauses make it hard for Java applications to meet quality of service guarantees. No matter how fast your application processes requests, a 30 second GC pause is going to ruin any guarantees you might want to make.

Shenandoah is a new GC algorithm designed to address this issue. We take a simple approach that allows us to do more work while your Java program is running so we can substantially reduce the time the JVM is paused. Our goal is to be able to garbage collect 100gb+ heaps in under 10ms.

This talk will focus on the current status of the project, the goals we've met so far, and what we are hoping to achieve in the coming year. We might even share some performance numbers.

Other people: Christine H Flood

What really happens to your Java code along the way to becoming machine code?

Red Hat has been developing an almost pauseless GC for OpenJDK which requires adding read barriers to every object access. We've also developed ARM64 versions of both the server and the client compilers. This has given us quite a bit of experience with the internals of the various methods of generating machine code inside the JVM. This talk will start with a brief tour of the various levels of code generation available and then open up the floor for questions from our panel.

Other people: Andrew Haley Andrew Dinn Christine H Flood

Caciocavallo has been one of the very first external projects to land in the OpenJDK repository and sponsored by the OpenJDK Porters Group. Named after a delicious cheese we're never tired of eating, it had the original purpose of refactoring the AWT peers to allow different implementations to be added to OpenJDK. The project evolved very quickly until it became itself a full implementation of AWT based on Swing with just enough abstraction to allow custom plugging into the Java2D system for rendering. As time passed, this characteristic was used to implement a GUI testing framework running on offscreen buffers to avoid the usual problems of focus stealing and random mouse moving that plague every other GUI testing framework (here everything is emulated!), and finally a full Web based backend to allow application to run remotely but still be visible on the local screen. This talk will cover the progress we have done over the years, we will show how easy is to implement a new backend and how this project could be used to give Wayland support to OpenJDK. We will show the testing framework and finally we will discuss about WebJDK, an idea to give more web oriented functionality to OpenJDK and use the web backend to enable fully cloud based applications.

Other people: Mario Torre

Current garbage collectors for OpenJDK all need to stop the application periodically to perform garbage collection tasks. This is a scalability bottleneck because those pause times are dependend on heap size. Shenandoah is a new garbage collector for OpenJDK, currently developed by Red Hat, that aims to reduce GC pause times to a minimum by implementing marking and object evacuation to run concurrently with application threads, and utilizing parallel garbage collection threads.

Current garbage collectors for OpenJDK all need to stop the application periodically to perform garbage collection tasks. This is a scalability bottleneck because those pause times are dependend on heap size. This is a problem for large-scale applications that require 100GB+ of heap. Shenandoah is a new garbage collector for OpenJDK, currently developed by Red Hat, that aims to reduce GC pause times to a minimum. Specifically, pause time are no longer dependend on heap size. It implements marking and object evacuation to run concurrently with application threads, and utilizing parallel garbage collection threads.

In this talk I want to introduce the Shenandoah GC, talk about our motivations, present the technical innvoations that enable Shenandoah to achieve concurrent marking and evacuation, compare Shenandoah with other garbage collectors, and finally give an overview of what we plan to do in the future.

Last year, we shared with the Free Java Devroom and the global OSS community our vision for a new open source monitoring and instrumentation tool for anyone running an open Java stack, along with our fledgeling implementation. Since then, we've been hard at work making this vision a reality. Our project has undergone various transformations, including becoming modular not just in terms of deployment but also from a source code perspective with the help of OSGi, a complete overhaul of the API for extending Thermostat, and an amazing visual makeover - attendees from last year may have trouble recognizing it on sight. Along the way we've also added new, compelling features such as detailed thread monitoring, heap dump and analysis, an Eclipse plugin interface, and more functionality available from the command line. Of course, we also had a lot of fun doing it.

In our talk, we will describe the current state of Thermostat, give a demo of what you can do out of the box, and build a toy plugin on the spot so that attendees can see how easy it is to add custom instrumentation.

Other people: Mario Torre

Since mid-2011 (when Gary Benson, the original author of Zero/Shark) left Red Hat's Java team), the Zero interpreter and Shark compiler have been basically unmaintained. A few months ago I picked up the project and fixed the outstanding issues (related to changes in Hotspot and LLVM) and started implementing a couple of significant improvements.

This talk will give a short summary about what Zero and Shark actually are, how they work, why they are relevant (even in the face of upcoming full ports for PowerPC and others), how it fits in the OpenJDK ecosystem, and then describe some of the more interesting details about what I did, in particular improved support for atomic operations, JSR 292/invokedynamic, interesting optimizations in both the compiler and the interpreter and more. Hopefully I will be able to present some interesting ports to other platforms like ARM or PowerPC, some benchmarks results as well as results from testsuites (TCK?). Finally, I'll give an outlook to the future, things that need to be done, open improvements, optimizations, etc.

IcedRobot is an attempt to bring the Android API on OpenJDK. It was first announced at Fosdem 2011, and after only two months of development and a team assembled during the customary Fosdem Free Java Hackers dinner, it was already able to translate most Android bytecode format to Java. This presentation will review the last year of development and will explain future direction and plans for the project.

Other people: Mario Torre

CacioCavallo is an award winning project sponsored by the OpenJDK porters group. The main project was about refactoring of the graphics stack of OpenJDK to allow of easy porting on various platform. It’s the abstract backend behind most ports and it has been used on field by commercial projects for companies in the embedded and automotive market. During the last year, two new projects have landed in the official Caciocavallo repositories: CacioWeb and Cacio Testing Framework. The first project allows for easy deployment even on platforms without any Java support (like Apple iPad) and makes extremely easy the deployment even without any Java plugin. CacioTest aims to make easy the testing of Graphics stack, providing a reliable, unobtrusive way to run UI and graphics related tests.

Other people: Clemens Eisserer Mario Torre