[Talk Proposal] Shenandoah: Why Do We Need Yet Another Garbage Collector? [Resend]
Abstract: 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. Bio: Christine H. Flood has been active in the programming languages community for more than two decades. She started work on Java Garbage Collection back when the JVM was just a reference implementation with a conservative garbage collector and she's had a hand in most of the existing OpenJDK algorithms. She's taken detours to do other things, but came back to the Java world to write just one more GC algorithm for Red Hat. Christine
----- Original Message -----
From: "Christine Flood" <chf@redhat.com> To: java-devroom@lists.fosdem.org Sent: Thursday, December 8, 2016 3:48:42 PM Subject: [Talk Proposal] Shenandoah: Why Do We Need Yet Another Garbage Collector? [Resend]
Abstract: 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.
Speaker Bios: Christine H. Flood has been active in the programming languages community for more than two decades. She started work on Java Garbage Collection back when the JVM was just a reference implementation with a conservative garbage collector and she's had a hand in most of the existing OpenJDK algorithms. She's taken detours to do other things, but came back to the Java world to write just one more GC algorithm for Red Hat.
Roman Kennke is a long time free Java (and Software) activist, originally involved in GNU Classpath since 2004, later participated in opening OpenJDK and since then is regular contributor to several parts of OpenJDK (AWT/Swing, general class library, lately Hotspot). After finishing Diploma in 2007 he was employed by aicas, who are building a hard realtime capable Java VM. During 2009 and 2010 worked for Sun Microsystems on Java Webstart. After a short period as contractor for JP Morgan, he's now a Prinipal Software Engineer at Red Hat, where he used to work on Thermostat, the Zero and Shark port of OpenJDK, and currently on the Shenandoah GC.
Christine _______________________________________________ java-devroom mailing list java-devroom@lists.fosdem.org https://lists.fosdem.org/listinfo/java-devroom
participants (1)
-
Christine Flood