Dongyun Jin , Patrick Meredith, Dennis Griffith, Grigore Rosu

Dongyun Jin, Patrick Meredith, Dennis Griffith, Grigore Rosu

University of Illinois at Urbana-Champaign

Garbage Collection for Monitoring Parametric

Properties

Outline

Motivation Property Static Analysis Double Lazy Garbage Collection Evaluation Conclusion

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

Event 2

Event 3

Event 4

Execute & Observe

Analyze

Execution Trace

Applications of Monitoring Development

Debugging Testing

Deployment Security Reliability Runtime Verification

Parametric Properties Properties referring to object instances The following property describes a bad behavior

between Each Collection c and Iterator i :

Generalize typestates Typestates are parametric properties with one

parameter

update(c )

next(i )

create(c , i )

update(c )

next(i )

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 [Barringer et al. 04]

Rule-Based Rewrite Properties (e.g. Context-Free Patterns, ..)

MOP [Rosu et al. 03] Formalism Independent Approach

many others

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

update(c ) next(i )

create(c , i )

update(c )

next(i )

update(c ) next(i )

create(c , i )

update(c )

next(i )

update(c ) next(i )

create(c , i )

update(c )

next(i )

update(c ) next(i )

create(c , i )

update(c )

next(i )

Challenge: Large number of monitors

Previously… Benchmark based on DaCapo 9.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 overhead 1

12% Memory overhead 1

MOP [Rosu et al. 03] 33% Runtime overhead 140% Memory overhead 1: Except 6(of 65)

crashes

Worst Cases – Runtime Overhead

bloat, UnsafeSyncMap

bloat, UnsafeSyncColl

pmd, UnsafeMapIterator

bloat, UnsafeMapIterator

avrora, UnsafeIterator

bloat, UnsafeIterator

bloat, HasNext

0% 500% 1000% 1500% 2000% 2500%

Tracematches MOP

19194%

From DaCapo 9.12 and DaCapo 2006-10 MR2

~ 4M Monitors

Worst Cases – Memory Overhead

bloat, HasNext

10% 100% 1000% 10000%

Tracematches MOP

1059%294%

57%2896%

2799%5%

39%2510%

41%1030%

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

Outline

Property Static Analysis

update(c )

next(i )

create(c , i )

update(c )

next(i )

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)

The Last EventParameter instances that need to be alive

update(c )

next(i )

create(c , i )

update(c )

next(i )

create

update(c )

next(i )

create(c , i )

update(c )

next(i )

create

Needed Events

create

update(c )

next(i )

create(c , i )

update(c )

next(i )

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)

The Last Event Parameter instances that need to be alive

create {c , i }

Needed Events

update(c )

next(i )

create(c , i )

update(c )

next(i )

create {c , i }

If any of these parameters are garbage collected,this monitor cannot trigger; can be collected

Needed Events

update(c )

next(i )

create(c , i )

update(c )

next(i )

update(c )

next(i )

create(c , i )

update(c )

next(i )

create {c , i }

update

update(c )

next(i )

create(c , i )

update(c )

next(i )

create {c , i }

update

update(c )

next(i )

create(c , i )

update(c )

next(i ) Needed Events

create {c , i }

update

create {c , i }

update {i }

update(c )

next(i )

create(c , i )

update(c )

next(i ) Needed Events

update(c )

next(i )

create(c , i )

update(c )

next(i )Needed Events

create {c , i }

update{i }

create {c , i }

update {i }{c , i }

update(c )

next(i )

create(c , i )

update(c )

next(i )Needed Events

create {c , i }

update {i }{c , i }

next {c , i }

update(c )

next(i )

create(c , i )

update(c )

next(i )

create {c , i }

update {i }{c , i }

next {c , i }

update(c )

next(i )

create(c , i )

update(c )

next(i )

If any of these are dead,then the current monitorcan be collected

Outline

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

Lazy removal 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)

Outline

Evaluation – Overall On average, based on the DaCapo 9.12

Benchmark 13 Programs and 5 Properties

1: Except 6(of 65) crashes

Tracematches MOPRV

(MOP + Garbage Collection)

Runtime Overhead 142%1 33% 15%

Memory Overhead 12%1 140% 39%

Evaluation – Worst Cases Runtime Overhead

bloat, HasNext

0% 500% 1000% 1500% 2000% 2500%

Tracematches MOP RV2119%

19194%

~ 4M Monitors

Evaluation – Worst Cases Memory Overhead

bloat, HasNext

10% 100% 1000% 10000%

Tracematches MOP RV

1059%294%

57%2896%

2799%5%

39%2510%

41%1030%

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

Dongyun Jin , Patrick Meredith, Dennis Griffith, Grigore Rosu

Documents

Transcript of Dongyun Jin , Patrick Meredith, Dennis Griffith, Grigore Rosu

core.ac.uk · CS322 Fall 2003: Programming Language Design - Lecture Notes – Grigore Rosu University of Illinois at Urbana-Champaign Abstract This report contains the complete lecture

10/14/20151 Programming Languages and Compilers (CS 421) Grigore Rosu 2110 SC, UIUC Slides by Elsa Gunter, based.

Traian Florin Serb¸anu¸t˘ a and Grigore Rosu¸˘ Matching ...fsl.cs.illinois.edu/pubs/NIER_ICSE_Poster.pdfTraian Florin Serb¸anu¸t˘ a and Grigore Rosu¸˘ University of Illinois

Sub Grigore Scu

rosu si negru vol.1

Colegiul National Grigore Moisil Onesti

MOP: An Efficient and Generic Runtime Verification Framework Feng Chen and Grigore Rosu University of Illinois at Urbana-Champaign.

mecanica clasica H.C Rosu

RV-ECU: Certifiable Runtime Verification for Automobiles Grigore Rosu

In rosu idea structure for the tpp

Alexandrescu Grigore, Satire Si Fabule

Leul Rosu Vol 2

An Overview of the K Semantic Frameworkfsl.cs.illinois.edu/pubs/rosu-serbanuta-2010-jlap.pdfAn Overview of the K Semantic Framework Grigore Ros, u and Traian Florin S, erbănut ă

10/25/20151 Programming Languages and Compilers (CS 421) Grigore Rosu 2110 SC, UIUC Slides by Elsa Gunter, based.

Automatically generated PDF from existing images. colectiv... · 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. rosu titu dumitru ungureanu marius rusescu grigore rosculete vasile

BRĂNIȘTEANU-ALBULESCU Bogdan-Grigore

Stendhal - Rosu Si Negru 1927 (v2.0)

JinHyeock Choi, DongYun Shin hppt://diffeo/FRD

SME Corectat Cei Cu Rosu

From Hoare Logic to Matching Logic Reachability Grigore Rosu and Andrei Stefanescu University of Illinois, USA.