Keynote: Industry GC Insights from OpenJDK
summary
OpenJDK work shows production GCs take about 10 years to production because collectors must integrate with JVMTI, compilers, class loading, debuggers and multiple architectures; moving tracing plus generational collectors dominate because memory is cheap and cloud instances provision roughly 1 GB per core, so trading memory to save CPU is often cheaper; HotSpot adds an access API to hide object layout, ZGC uses few-thread early-start scheduling to cut tail latency, and Netflix reports lower cancellation rates after switching to generational ZGC.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 0:26Garbage collector evolution in OpenJDK
- 3:16Avoiding GC lock-in
- 7:53Why GC takes a decade
- 12:50Memory scaling in deployments
- 18:32Tracing GC trade-offs
- 26:04Generational GC scalability
- 31:50Latency in interactive applications
- 40:37Key takeaways
- 43:28Q&A: Virtual threads impact
- 44:56Q&A: Multiple GC options
- 46:01Q&A: GC on microcontrollers
- 47:48Q&A: Memory scaling feedback
- 48:51Q&A: Benchmarking GC
- 51:19Q&A: Heap size myth
- 53:02Q&A: Context in GC research
- 54:47Q&A: GC vs manual memory
related talks
48mZGC: A Decade of Redefining Java Performance
25mGarbage Collection Primer
51mJava 10/11 Memory Management and GC
35mJava at Speed: Building a Better JVM
46mTrash Talk - Exploring the Memory Management in the JVM
43mGarbage Collection in Java: The Performance Benefits of Upgrading
50mTrash Talk - Exploring the JVM memory management
46mPrinciples of Memory Management in Java