1 / 29

On Using Tracer Driver for External Dynamic Process Observation

On Using Tracer Driver for External Dynamic Process Observation. Pierre Deransart WLPE 2006. Les unités de recherche. Rocquencourt. Loria. Rhône-Alpes. Irisa. Sophia Antipolis. Futurs. BASIC MOTIVATIONS. Dynamic Program Analysis: typical recent works are based on trace analysis

avent
Download Presentation

On Using Tracer Driver for External Dynamic Process Observation

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. On Using Tracer Driver for External Dynamic Process Observation Pierre Deransart WLPE 2006 Pierre Deransart WLPE 06

  2. Les unités de recherche Rocquencourt Loria Rhône-Alpes Irisa Sophia Antipolis Futurs Pierre Deransart WLPE 06

  3. BASIC MOTIVATIONS • Dynamic Program Analysis: • typical recent works are based on trace analysis • Ernst & al. 2001: “Dynamically discovering likely program invariants…” from data computed by dynamic execution • Denmat & al. 2005 “Data mining and Cross-checking of Execution Traces…” from a collection of traces • Zaidman & al. 2005 “Applying Webmining Techniquesto Execution Traces…” Pierre Deransart WLPE 06

  4. WHY TRACES ? • Any phenomenon, any open system leaves traces • Walking (persistent foot traces) • Sedimentation (temporally accumulated traces), fossils • Particles (light): objects only known by their physical or chemical properties • Programs (outputs, observation) • Communication (messages) • Discourse abstract • Human Memory…(persistent and reactive) • Traces are everywhere: we only know processes by their traces Pierre Deransart WLPE 06

  5. OBSERVING PROCESSES • Everybody watches everyones….. • Everybody receives from everyone • Everybody sends messages to … Pierre Deransart WLPE 06

  6. « Leave traces, not proofs, only traces give dreams » • René Char • Poète • (1907-1988) Pierre Deransart WLPE 06

  7. We know and define complex objects from the traces they leaveWe know complex programs behaviour by analyzing their tracesCausal analysis is not tractable likely causalityTRACE modeling is the right approach Pierre Deransart WLPE 06

  8. BUT, what IS a TRACE ???HOW to ANALYSE IT ??? • I want to leave these questions open • ….small demo Pierre Deransart WLPE 06

  9. What IS a TRACE ??? the answer is:Any possible understandable information related to an observed phenomenon • PRO • Any observing device will find in the trace what it needs • If a process needs instrumentation to produce a trace, this need only to be made once • Analysis tools may be developed independently Pierre Deransart WLPE 06

  10. CON:- it is not possible to broadcast such a huge information flow (communication slowing down)-then the observed process always computes a huge amount of unused data (construction slowing down) Pierre Deransart WLPE 06

  11. SPECIFIC ASPECTS • Needs for trace standardization • All levels of granularity accepted • Different kinds of informations included (levels of abstraction) • Each analyser must be able to recognize its relevant information • Use of XML to define possible standards Pierre Deransart WLPE 06

  12. SEEMS an UNREALISTIC GOAL !!! the answer is:Driven Tracer • SPECS • selects in the trace what the observer needs • keeps tracer listening to the analyzers (dialog between server and clients) • Leave the tracer to distribute and broadcast each specific trace • Allow workload repartition between tracer and analysers Pierre Deransart WLPE 06

  13. ORGANISATION • History • Virtual Full Trace • Processes organization • Workload analysis • Driver requirements • Conclusions Pierre Deransart WLPE 06

  14. HISTORY • Ducassé, Opium: versatile analyzers • Ducassé, Noyer, 1994, JLP: independence of tracer and analyzers • Langevine & Ducassé & Deransart, 2003, ICLP’03: Codeine, First Driven Tracer approach implementation for GNU-prolog • Deransart & all, 2004, OADymPaC project: client/server architecture, trace standardization (XML) for interoperability • Langevine & Deransart & Ducassé, 2004, LNAI 3010: model of « generic trace » for constraint programming • Langevine & Ducassé, 2005, AADEBUG, WLPE: Driven Tracer for FD constraints and experimentation • Now, 2006: « theory » of generic trace and driven tracer = • virtual full trace Pierre Deransart WLPE 06

  15. VIRTUAL FULL TRACE (definition) • unbounded sequence of trace events of the form • et: (t, at, St+1) • et: unique identifier of the event • t: chrono. Time of the trace • St = p1,t..., pn,t : parameters at chrono t. In a trace event the parameters are called attributes and St the full current state • at: action characterizing the step of the state St to the state St+1. It can be described by a set of transformations which describes the operations carried out on the current state Pierre Deransart WLPE 06

  16. EFFECTIVE TRACE • a full trace of the form • et: (t, At) • such that, starting from the knowledge of (St,At) one can deduce (at, St+1). • At denotes a set of attributes. The effective trace is the trace emitted by a tracer, which is actually ``visible''. • The virtual full trace is a particular case of effective trace where the attributes At are the actions at and the parameters St. Pierre Deransart WLPE 06

  17. EXAMPLE (effective trace) • 1 1 Call: '$call$'(bench(2)) • 2 2 Call: bench(2) • 3 3 Call: 2>0 • 3 3 Exit: 2>0 • 4 3 Call: _182 is 2-1 • 4 3 Exit: 1 is 2-1 • 5 3 Call: bench(1) • .... Pierre Deransart WLPE 06

  18. INCREMENTAL TRACE • the attributes are such that only the changes affecting the current state are noted. • et: (t, Deltat+) • where Deltat+ contains the description of the actions which modify the values of the parameters at moment t. • To remain a full trace, this trace must satisfy the following condition: • For every t • (t, at, St+1) can be deduced from (St, Deltat+) Pierre Deransart WLPE 06

  19. CLIENT/SERVER architecture Pierre Deransart WLPE 06

  20. CLIENTS/server architecture Pierre Deransart WLPE 06

  21. CLIENTS / server architecture • Workloads are distributed among • Program (without connections with tracer) T_prog • Tracer (parameters and attributes computation) T_core + T_extract • Driver (dialog and attributes selection) T_cond • Broadcasting (all traces encoding) T_encode-and-com ==================================================== • Reception (dialog and post-selection) T_filter • Trace decoding T_decode • Trace rebuilding T_rebuild • Analyzer execution T_ana Pierre Deransart WLPE 06

  22. CLIENTS / server architecture • Process • --------------- • | | • T_prog + T_core1 • Tracer and Driver • ----------------------------------------------- • | | • T_core2 + T_cond + T_extract + T_encode-and-com • ========================================================= • Analyzer • ------------------------------------------ • | | • T_filter + T_decode + T_rebuild + T_ana Pierre Deransart WLPE 06

  23. Workload balance ================================================== Analyzer --------- | | T_ana • Process and Tracer • --------------- • | | • T_prog + T_core Analyzer --------- | | T_filter Driver --------- | | T_cond Analyzer --------- | | T_rebuild Tracer --------- | | T_extract Tracer ----------------- | | T_ encode-et-com Analyzer --------- | | T_decode Pierre Deransart WLPE 06

  24. OBSERVATIONAL SEMANTICS • Two levels • Objects level: read the trace (parameters and attributes description and relationships) • Trace steps level: understand underlying model (full state transformations) • It may be a rule semantics (finite number of rules) • a: Condition(S)  S’ := a(S) Pierre Deransart WLPE 06

  25. OBSERVATIONAL SEMANTICS • The OS is usually not a complete operational semantics • Knowing S_t and S_t+1, one rule applies but the knowledge of S_t is not always sufficient to know which rules can be applied (to be studied) • Not all attributes can be formalized in the OS (one should have a full model of the observed process) • There may be as many OS than observers Pierre Deransart WLPE 06

  26. DRIVER REQUIREMENTS • In addition to the tracer’s work, it must • Analyze trace queries • Store and manage requested trace patterns • Manage the dialog between server (tracer) and clients (analyzers) • Tell the tracer what to extract and to broadcast Pierre Deransart WLPE 06

  27. GENERAL CONCLUSION : • Possibility to implement very large virtual full trace without slowing down excessively the observed process • More sophisticated analyses will be performed, larger can be the virtual full trace • Trace selection and filtering can be very efficient using a tracer driver • Effective trace size can be reduced by different means: compression (delta and classical compression) or abstraction (transfer more complex objects) Pierre Deransart WLPE 06

  28. QUESTIONS • Is a « never more » - extensible full virtual trace possible? • How to parameterize the compression (to specify the level of abstraction of communicated objects)? • Full virtual trace standardization (work on constraint problems), how? XML effort? • OS discovery from trace (trace mining), assuming trace objects are known? • Consider other fields where the notion of trace is relevant? • TRA4CP project Pierre Deransart WLPE 06

  29. Thank you! Pierre Deransart WLPE 06

More Related