Building custom memory profilers In# Gonzalez- Herrera Diverse Team Advisers: Johann Bourcier and Olivier Barais
What are and why we need custom memory profilers? Developers think in terms of high- level abstrac#ons High- level abstrac#ons everywhere!!! Development frameworks Tooling- support is geing bejer DSLs Built atop existent technologies => using subop*mal tools when no op*on is available 2
Aspects in Kermeta 3 K3 defini#on User s mental model Real, low- level, representa#on 3
State- of- the- art profilers view? Object Class Name Instance Size A@32443234 A sizeof(a) + sizeof(a.a) AAspectProperty@fdsfdf3343 AAspectProperty sizeof(aaspectproperty) + sizeof(aaspectproperty.b) AAspect1Property@dfds\j566 AAspect1Property sizeof(aaspect1property). 4
Again why custom memory profilers? For execu#ves: Memory profilers for Java mostly offer support for standard Java abstrac#ons. As well as we None need at all custom or just editors, restricted we support need for custom maintenance tools addi#onal abstrac#ons But when there is support, solu#ons perform poorly This forbid their usage at run#me 5
What problem we face? Compute values on each subset entry A0 entry value key key value value key key value C A B C A B A.a B.b A.a B.b 6
Problem in detail The heap is a DAG with thousands of nodes. Such a DAG changes a lot over #me A memory analysis is: 1. Solve a subgraph matching problem (NP- complete) 2. Compute values on the subgraph Most queries are tractable OQL (Eclipse MAT, VisualVM) Cypher (internal experiments) Tractable doesn t mean ready for produc#on environments Preprocessing is a bojleneck Duplica#ng the DAG is a poor choice 7
Brief DSL s descripfon Subgraph specifica#on User- defined data Collec#ons Anonymous lambda expressions to operate on collec#ons 8
DSL for custom memory profiling Trade- off between expressiveness and performance The computa#onal model is simple and explicit Linear #me execu#on on the number of objects Easy to see the cost of profiling Execute the DSL by traversing the DAG of live objects Support many queries, par#cularly resource consump#on queries 9
Language implementafon Java XText JVMTI agent Our DSL JVMTI plugin in C JVM Applica#on Op*miza*on is the main issue in the implementa*on Avoid precompu#ng unneeded data by using variability Avoid traversing leaf nodes Reordering expressions Minimizing number of graph traversals 10
EvaluaFon Performance gain 1. Impact of Analysis on the Total Execu#on Time 2. Comparing Analysis Time for Simple Asser#on 3. Analysis Time in Real Scenarios Discussion on expressiveness 11
Impact of Analysis on the Total ExecuFon Time Very simple analysis Execute the analysis many #mes Use different analysis techniques 12
Comparing Analysis Time for Simple AsserFon 13
Analysis Time in Real Scenarios OSGi- based applica#ons Compute the memory consump#on of each component 14
Discussion on Language Expressiveness Our approach Cypher Easy to reason about its performance and expressiveness OQL enough 15
Conclusions and Future Works Tooling support for high- level abstrac#ons is incomplete. We lack tools to deal with maintenance tasks. We provide a DSL to define custom memory profilers which show low overhead Performance has been evaluated Expressiveness was discussed For a new DSL, is it possible to automate the genera#on of a profiler? 16
? 17