1 / 37

Dongyun Jin , Patrick Meredith, Dennis Griffith, Grigore Rosu

Garbage Collection for Monitoring Parametric Properties. Dongyun Jin , Patrick Meredith, Dennis Griffith, Grigore Rosu. University of Illinois at Urbana-Champaign. Outline. Motivation Property Static Analysis Double Lazy Garbage Collection Evaluation Conclusion. Monitoring.

kelly-montoya
Download Presentation

Dongyun Jin , Patrick Meredith, Dennis Griffith, Grigore Rosu

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. Garbage Collection for Monitoring Parametric Properties DongyunJin, Patrick Meredith, Dennis Griffith, GrigoreRosu University of Illinois at Urbana-Champaign

  2. Outline • Motivation • Property Static Analysis • Double Lazy Garbage Collection • Evaluation • Conclusion

  3. Monitoring • Scalable technique for ensuring software reliability • Observe run of a program • Analyze execution trace against desired properties • React/Report using handlers (if needed) … Program Event 1 Analyze Execute & Observe ? Event 2 Event 3 Event 4 Execution Trace …

  4. Applications of Monitoring • Development • Debugging • Testing • Deployment • Security • Reliability • Runtime Verification

  5. Parametric Properties • Properties referring to object instances • The following property describes a bad behavior between Each Collectioncand Iteratori : • Generalize typestates • Typestates are parametric properties with one parameter update(c ) next(i ) update(c) create(c , i ) update(c) next(i )

  6. Parametric Property Monitoring Systems • Tracematches [de Moor et al. 05] • Regular Patterns • PQL[Lam et al. 05] • Context-Free Patterns • PTQL[Aiken et al. 05] • SQL-like language • Eagle then RuleR [Barringeret al. 04] • Rule-Based Rewrite Properties (e.g. Context-Free Patterns, ..) • MOP [Rosuet al. 03] • Formalism Independent Approach • many others

  7. Parametric Monitoring in MOP • Keep one monitor for each parameter instance • A parameter instance binds parameters to objects • E.g., • Each monitor knows nothing of parameters;operates exclusively on only one trace slice

  8. Parametric Monitoring in MOP • Keep one monitor for each parameter instance • A parameter instance binds parameters to objects • E.g., • Each monitor knows nothing of parameters;operates exclusively on only one trace slice Trace: create(c1, i1) create(c1, i2) next(i1) update(c1) next(i2)

  9. Parametric Monitoring in MOP • Keep one monitor for each parameter instance • A parameter instance binds parameters to objects • E.g., • Each monitor knows nothing of parameters;operates exclusively on only one trace slice Trace: create(c1, i1) create(c1, i2) next(i1) update(c1) next(i2) (c1, i1) Trace Slice: create next update (c1, i2)Trace Slice: create update next

  10. Parametric Monitoring in MOP • Keep one monitor for each parameter instance • A parameter instance binds parameters to objects • E.g., • Each monitor knows nothing of parameters;operates exclusively on only one trace slice Trace: create(c1, i1) create(c1, i2) next(i1) update(c1) next(i2) update(c ) next(i ) update(c) (c1, i1) Trace Slice: create next update create(c , i ) update(c) next(i ) (c1, i2)Trace Slice: create update next update(c ) next(i ) update(c) create(c , i ) update(c) next(i )

  11. Parametric Monitoring in MOP • Keep one monitor for each parameter instance • A parameter instance binds parameters to objects • E.g., • Each monitor knows nothing of parameters;operates exclusively on only one trace slice Trace: create(c1, i1) create(c1, i2) next(i1) update(c1) next(i2) update(c ) next(i ) update(c) (c1, i1) Trace Slice: create next update create(c , i ) update(c) next(i ) (c1, i2)Trace Slice: create update next update(c ) next(i ) update(c) create(c , i ) update(c) next(i ) Challenge: Large number of monitors

  12. Previously… • Benchmark based on DaCapo9.12 [Blackburn et al. 06] • On average for 65 cases (13 examples 5 properties) • Tracematches[de Moor et al. 05] • One of the most memory efficient monitoring systems • 142% Runtime overhead1 • 12% Memory overhead1 • MOP [Rosuet al. 03] • 33% Runtime overhead • 140% Memory overhead 1: Except 6(of 65) crashes

  13. Worst Cases – Runtime Overhead From DaCapo 9.12 and DaCapo 2006-10 MR2 2119% 448% 19194% 569% 637% 311% OOM 1203% OOM 571% 1359% ~ 4M Monitors 746% 1942% 716%

  14. Worst Cases – Memory Overhead From DaCapo 9.12 and DaCapo 2006-10 MR2 1059% 294% 57% 2896% 5% 2799% OOM 3439% 1082% OOM 39% 2510% 41% 1030%

  15. Goal: Reduce the Runtime/Memory Overhead • Static • Program Analysis [Bodden et al. 09, 10], [Dwyer et al. 10], … • Property Analysis • Dynamic • By using information from property analysis,garbage collect monitorswhen they become useless during monitoring

  16. Outline • Motivation • Property Static Analysis • Double Lazy Garbage Collection • Evaluation • Conclusion

  17. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis isformalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i )

  18. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis is formalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i )

  19. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis is formalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i )

  20. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis is formalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i ) Needed Events

  21. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis is formalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i ) Needed Events

  22. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis is formalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i ) Needed Events If any of these parameters are garbage collected,this monitor cannot trigger; can be collected

  23. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis is formalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i )

  24. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis is formalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i )

  25. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis is formalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i ) Needed Events

  26. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis is formalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i ) Needed Events

  27. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis is formalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i ) Needed Events

  28. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis is formalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i ) Needed Events

  29. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis is formalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i )

  30. Property Static Analysis • Property analysis tells us when monitors are unnecessary • Our analysis is formalism independent; we only show it for FSM monitors (see paper for CFG monitors) update(c ) next(i ) update(c) create(c , i ) update(c) next(i ) If any of these are dead, then the current monitor can be collected

  31. Outline • Motivation • Property Static Analysis • Double Lazy Garbage Collection • Evaluation • Conclusion

  32. Double Lazy Garbage Collection • Indexing Trees map parameter instances to monitors • Lazy propagation of info about dead parameter instances • Eager propagation yields high runtime overhead (like TM) • Idea: propagate when monitors are updated for other reasons • Lazyremoval of useless monitors • Removal is expensive (monitor can belong to many trees) • Idea: just mark unnecessary monitors, then clean up later (technical; see paper for details and proof of correctness)

  33. Outline • Motivation • Property Static Analysis • Double Lazy Garbage Collection • Evaluation • Conclusion

  34. Evaluation – Overall • On average, based on the DaCapo 9.12 Benchmark • 13 Programs and 5 Properties 1: Except 6(of 65) crashes

  35. Evaluation – Worst Cases Runtime Overhead From DaCapo 9.12 and DaCapo 2006-10 MR2 2119% 448% 116% 19194% 569% 251% 637% 311% 118% OOM 1203% 178% OOM 571% 188% 1359% ~ 4M Monitors 746% 212% 1942% 716% 130%

  36. Evaluation – Worst Cases Memory Overhead From DaCapo 9.12 and DaCapo 2006-10 MR2 1059% 294% 169% 57% 2896% 1512% 5% 2799% 236% OOM 3439% 1045% OOM 1082% 420% 39% 2510% 886% 41% 1030% 159%

  37. Conclusions • Garbage collection for parametric monitoring • Formalism-independent • Directed by property static analysis • Double Lazy Garbage Collection • Lazy propagation of info • Lazy removal of monitors • Evaluation • Lowest runtime overhead parametric monitoring system • Reasonable memory overhead

More Related