GCspy for Rotor

1. Richard Jones, Hanspeter Johner, Marion Sébastien University of Kent R.E.Jones@kent.ac.uk sm244@kent.ac.uk GCspyforRotor

2. GCspy Heap Visualisation Framework • Motivation & requirements • Abstractions & Architecture • Benefits • Rotor implementation • New views • Conclusion Developed by Richard Jones and Tony Printezis 2

3. Motivation • GCs have (almost) chaotic behaviour! • Visualisation allows • concise insight into GC’s behaviour • profiling / debugging • Avoid collecting / analysing very large traces • “a picture is worth a thousand awk invocations!” • T.Printezis 3

4. Requirements • Portability • Adaptability • Extensibility • Scalability • Responsiveness 4

5. GC Visualiser Component e.g. generation Space Block e.g. memory block Tile Attribute e.g. used space Stream Event e.g. start mark phase Event Abstractions 5

6. Application Copy GC MS GC Space Renderer 0 Space Renderer 1 Data collection Init Copy Driver MS Driver Space 0 Space 1 Control Stream 0 Stream 1 Control Stream 0 Stream 1 Stream 2 Used Roots Objects Cards Marked Server-Interpreter Client-Interpreter Event filters Event filters Socket Communications Communications GC/VM dependent GCspy generic Architecture Visualiser Virtual Machine 6 MSR Rotor Presentation Day

7. GCspy Appel-style Nursery space- separators show history Tile Information Event History view of the Mature M-S space 8 Streams 6 Spaces Magnifier Histogram view of the Mature space’s free-lists View selectors 7

8. CLR Profiler • Available since 2003 for the .NET platform • Strengths: • Intended for the application developer • Detailed exploration of the application’s memory behaviour • Different views • Weaknesses: • Slows down program’s execution from 10 to 100 times • Huge log file (can consume gigabytes of space) • Needs the application to be compiled in debug mode • Not portable (only for .NET on windows)

9. GCspy Benefits • Loosely coupled to VM  rapid development of visualisation of new algorithms. • Visualise a variety of data structures (card-tables, free-lists, trains…). • Variety of dynamic views. • Connect/disconnect to running VMs on the fly. • No overhead outside data gathering periods. • Designed for very large heaps. • Small trace files (can store and replay). 9

10. Rotor Server • RMTk (MMTk for Rotor): • What is MMTk (Memory Management Toolkit)? • Extensible and portable framework • Permits efficient and reliable build of Garbage Collectors • Originally developed for JVMs • What is RMTk • Port of MMtk to Rotor by Andrew Gray • Relies on GCJ (Java compiler developed by the GCC team)

11. Why RMTk? • Wider range of GCs • Easy and efficient implementation of new GCs • Currently implemented: • Mark-Sweep • Semispace Copying • Generational Copying (copy both generations) • Generational Mark-Sweep (copy young gen, M-S old gen)

12. Technical details • Rotor's implementation: • Use of different GCs • Requires one build per GC • Builds: • With GCspy support or not • With MMTk optimizations turned on or not • One RMTk library per collector: • Contains the GCspy drivers specific to that collector • Adds wrappers to handle communication between RMTk and GCspy • Only one GCspy server library

13. Application Rotor Virtual Machine MMTk GC0 Copy GC MMTk GC1 MS GC Init Data collection Init Copy Driver MS Driver Copy Driver MS Driver Used Roots Used Roots Objects Cards Marked Objects Cards Marked Server-Interpreter Event filters Communications MMTk's integration GCspysynchronous other methodspossible GCspy abstractions allow easy replacement of data gathering mechanisms, collectors and VMs. 13

14. Rotor (Modified) RMTk mmtk mmtktransform SSCLI Legend: jmtkbuild a b : a generates b VM a gcjmmtk b : a composes b a b : a is used and modified by b RMTk library gcspyglue a b : a interacts with b libgcspy.so GCSpy Client Server Components interaction

15. Components instrumented • A variety of different data structures have been instrumented • Copy spaces (contiguous allocation) • Mark-Sweep spaces • Remembered sets • Segregated free-lists

16. GCspy client • New plugin view mechanism: • Easy development and incorporation of new views • History is now just another plugin • Writing a new plugin view: • Extend PluginListener (trivial — 9 lines of code) • Extend PluginFrame (depends on complexity of the view) • Save as a jar file in the plugins directory • Plugin manager: • Discovers available plugins • Maintains a list of activated plugins • Menu to choose the views to enable

17. Benchmarks • We need better benchmarks! • Synthetic programs OK as stress tests • Real programs for real understanding • Documented • Open source • Existing benchmarks • Zorn • Krintz

18. Methodology • 1) RMTk without GCspy • 2) RMTk + GCspy compiled in, GCspy client not connected • 3) RMTk + GCspy compiled in, GCspy client connected • Object-level data acquisition • Performance overhead • GCspy client connected: • 8.47% average • 36.1% worst case • GCspy client disconnected: • Less than 2.5% average • Caveat: • Rotor/RMTk is significantly slower than native Rotor.

19. Performance

20. Conclusion • GCspy incorporated into Rotor through RMTk. • Several GCs available, all instrumented for GCspy. • New GCspy views. • Good performance. • Documentation: Server API, GCspy client. • Need interesting, open source benchmarks 20

21. Demo Play trace Launch gcspy

22. Questions?