1 / 17

Removing GC Synchronisation

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

pamelia
Download Presentation

Removing GC Synchronisation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Removing GC Synchronisation Andy C. King and Richard Jones University of Kent at Canterbury

  2. Overview • The Problem • An Observation • L & S Heaplets • Implementation • A Fly in the Ointment • Swatting the Fly • Measurements • Future Work

  3. 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

  4. 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

  5. L & G Heaplets T1 G L1 T2 L2

  6. 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

  7. 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

  8. 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)

  9. 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 }

  10. 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

  11. Swatting the Fly (2) T1 G OL1 L1 T2 OL2 L2

  12. 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

  13. Swatting the Fly (4) T1 G OL1 L1 T2 OL2 L2

  14. Measurements

  15. Measurements (2)

  16. Future Work • Finally get the bloody numbers from the GC…

  17. Q&A Andy C. King and Richard Jones University of Kent at Canterbury

More Related