Improving Garbage Collection Observability with Performance Tracing
summary
Tracing hooks compile with 14 lines of Rust and sit inactive with essentially zero runtime cost; activating them via eBPF tracing records every GC event so engineers can measure actual packet sizes, timings and contention. Process-edges traces reveal consistent 25-item packets causing serial execution; bucket-open traces expose thread-starvation and a finalization hotpath that serializes fop, and an uncovered LSearch file-handle bug whose fix restores scalability. Active tracing adds up to ~12% collector overhead in worst cases.
AI-written summary · about
chapters (12)
- 0:00Garbage collection debugging intro
- 0:27GC debugging limitations
- 3:37Performance tracing for GC issues
- 7:07MMTk collector design
- 8:30Critical tracing points in MMTk
- 9:57Tracing overhead and effort
- 10:18Transitive closure scalability case
- 13:27Load balancing with tracing
- 15:40Application bugs discovered
- 16:42Tracing framework flexibility
- 17:02Summary and future of GC debugging
- 17:46Q&A on trace data and eBPF
related talks
41mThe Future of Tracing
25mPerfect Match: Correlating Continuous Profiling with Distributed Tracing for Stronger Observability
44mObservability Tools C++: Beyond GDB and printf - Tools to Understand the Behavior of Your Program
35mLinux Tracing updates
31mPeeking into Ruby: Tracing Running Code
30mBeyond OpenTracing
15mTuning OTel Collector Performance Through Profiling
42mHow Much Is Tracing? Measuring the Overhead Caused by the Tracing Infrastructure