Shenandoah: the garbage collector that could (part 2)
Day 1 / 17:00 / Track 2 / Lang: RUAttention! To fully understand everything Aleksey will tell us in this talk, we strongly encourage you to watch the first part of "Shenandoah: the garbage collector that could": https://youtu.be/CnRtbtis79U
Once you deal with major GC phases and make them concurrent, the GC hiccups are then caused by the shorter, but still important (sometimes stop-the-world) activities in-between the concurrent phases. The issues include fast GC roots scans, interaction with GC-aware language features (for example, weak references), dealing with safepoint machinery pitfalls, heap management and interaction with operating system, etc. This talk dives deeper into actual problems faced by the low-latency collector like Shenandoah, what can JVM developers do about it, and what cautious application writers may consider when designing their low-latency Java applications.
Aleksey Shipilev, Red Hat
shipilevAleksey is working on Java performance for 10+ years. Today he is employed by Red Hat, where he does OpenJDK development and performance work. Aleksey develops and maintains a number of OpenJDK subprojects, including JMH, JOL, and JCStress. He is also an active participant in expert groups and communities dealing with performance and concurrency. Prior joining Red Hat, Aleksey was working on Apache Harmony at Intel, then moved to Sun Microsystems, which was later consumed by Oracle.