170 likes | 294 Views
This paper discusses the challenges of synchronization in multi-threaded applications and explores the innovative concept of heaplets for managing thread-local objects. By utilizing escape analysis, the implementation allows for efficient garbage collection without the need to suspend other threads for local objects, thus improving performance. The authors address potential issues arising from dynamic class loading and share techniques to classify objects as truly local or optimistically local. Measurements of this approach are discussed, and future work aims to refine garbage collection efficiency.
E N D
Removing GC Synchronisation Andy C. King and Richard Jones University of Kent at Canterbury
Overview • The Problem • An Observation • L & S Heaplets • Implementation • A Fly in the Ointment • Swatting the Fly • Measurements • Future Work
The Problem • Concurrency in multi-threaded applications • Synchronisation is necessary • Language level • synchronized • VM level • mutator and garbage collector (GC) threads • suspending threads before collecting • the latter can be quite costly
An Observation • Objects may be thread-local (L) • Reachable only within their allocating thread • do not need synchronisation for such objects • Can manage these objects locally • Place in per-thread heap regions called heaplets • No need to stop other threads to collect such objects • Shared objects (G) go in global heap
L & G Heaplets T1 G L1 T2 L2
Implementation • Variation on Steensgaard [Stee00] • Escape analysis technique • automatically determine local objects • mark their allocation sites • patch to use appropriate heaplet • Flow-insensitive • Context-sensitive (specialisation) • performed at runtime
Implementation (2) • Operates on a snapshot of the world • set of classes loaded at that point in time • JDK 1.22_06 Production Release for Solaris • new GC with heaplets • support specialisation • patches applied in interpreter • patched/specialised methods can be JIT’ed
A Fly in the Ointment • Dynamic class loading • Class loaded after snapshot • May override method containing L allocation site • Shares the object • L allocation site now S • (transitive closure)
A Fly in the Ointment (2) • 1 classA { • 2 publicvoid do(Object o) { } • 3 } • 4 classMain { • 5 publicstaticvoid main(String[] args) { • 6 A a = newA(); • 7 foo(a); • SNAPSHOT ANALYSIS • 30 A a’ = newA’(); LOAD CLASS A’ • 31 foo(a’); • 32 } • 33 publicstaticvoid foo(A inA) { • 34 Object o = newObject(); • 35 inA.do(o); • 36 } • 37 }
Swatting the Fly • Truly shared (G) • reachable from >1 thread • G heap • Truly local (L) • reachable from exactly 1 thread • can prove type • L heaplet • Optimistically local (OL) • reachable from 1 thread • cannot prove type • OL heaplet
Swatting the Fly (2) T1 G OL1 L1 T2 OL2 L2
Swatting the Fly (3) • Analyse new classes immediately • Compare methods • If mismatched, OL sites are broken • Class is non-conforming • OL heaplet becomes G • can be done very cheaply • only OL heaplets of referring threads are affected
Swatting the Fly (4) T1 G OL1 L1 T2 OL2 L2
Future Work • Finally get the bloody numbers from the GC…
Q&A Andy C. King and Richard Jones University of Kent at Canterbury