1 / 14

Sampling profiler for Rotor as part of optimizing compilation system

Sampling profiler for Rotor as part of optimizing compilation system. Sofia Chilingarova, St-Petersburg, Russia. Prof. Vladimir O. Safonov St-Petersburg, Russia. Agenda. Problem Statement Rotor Sampling Profiler Implementation Results. Problem Statement.

metea
Download Presentation

Sampling profiler for Rotor as part of optimizing compilation system

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. Sampling profiler for Rotor as part of optimizing compilation system Sofia Chilingarova, St-Petersburg, Russia Prof. Vladimir O. Safonov St-Petersburg, Russia

  2. Agenda • Problem Statement • Rotor Sampling Profiler Implementation • Results

  3. Problem Statement • Rotor does not implement optimizations in JIT-compiler • To implement optimizations runtime profiling is needed • Sampling based profiler:the best option, rather full information by low cost

  4. Typical Optimizing Dynamic Compilation Subsystem Architecture IL (bytecode, CIL) Base Compiler/ Interpreter Executable Code Multilevel Optimizing Compiler Profiling Data Compilation Queue Profiler Data Controller Methods list Profiling plan

  5. Rotor Sampling Profiler Implementation • Goals • Profiling Subsystem Architecture • Data Storage Structure • Self-Tuning • Integration withRotor

  6. Goals • To estimate individual method calls frequency • To construct a Call Graph • To achieve a reasonably low cost: • small total overhead of profiling • avoid suspending user threads for a long time • To make good use of existing Rotor facilities

  7. Profiling Subsystem Architecture SSCLI Threads Profiler marks managed threads buffer Profiler Marking- Thread local queue raw samples data Manager-Thread Global queue Data Storage

  8. Data Storage Structureprevious approaches a bunch of samples DCG (Dynamic Call Graph) PCCT (Partial Call Context Tree)

  9. Data Storage Structure - our approach

  10. Self-Tuning • When taking a sample: if “visited” frame is encountered, stack lookup is completed • The sample is marked with a “visited” mark • When processing samples: if marked sample contains only 1 frame data (a topmost frame), a special “repetitions” counter is incremented • Profiling interval is tuned based on “repetitions” counter value when a fixed number of samples is processed

  11. Integration withRotor • Threads are stopped at “safe points” to get profile • Just as they are stopped for GC or debugging • Inherent SSCLI “Stack Walk” mechanism is used to collect managed stack samples • Internal SSCLI VM hash tables and synchronization locks are used to store and maintain profile data

  12. Results: testing environment • Tests from Rotor test suit have been used: sscli\tests\bcl\threadsafety • Many threads execute the same code • Measures used: • statistical correlation of total individual method calls counters • Arnold & Ryder’s Tree Overlap Percentage Measure • Self-tuning turned off for simplicity of measurement • But the best results were obtained with the same interval, which had been set automatically (100ms) • Average value from 10 subsequent runs is counted

  13. Results

  14. Questions Author: Sofia Chilingarova, e-mail: sofie-chil@hotmail.ru

More Related