1 Pierre Deransart WLPE 061 On Using Tracer Driver for External Dynamic Process Observation Pierre...

1

Pierre Deransart WLPE 06 1

On Using Tracer Driver for External Dynamic Process Observation

Pierre Deransart

WLPE 2006

2


LoriaRocquencourt

Sophia Antipolis

Irisa

Rhône-Alpes

Futurs

Les unités de recherche

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 Techniques to Execution Traces…”

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

5


OBSERVING PROCESSESEverybody watches everyones…..

Everybody receives from everyone

Everybody sends messages to …

6


« Leave traces, not proofs, only traces give dreams »

René Char

Poète

(1907-1988)

« Laisser des traces, pas des preuves, seules les traces peuvent faire rêver »

René CharPoète(1907-1988)

7


We know and define complex objects from the traces they leave

We know complex programs behaviour by analyzing their traces

Causal analysis is not tractable likely causality

TRACE modeling is the right approach

8


BUT, what IS a TRACE ???

HOW to ANALYSE IT ???

I want to leave these questions open

….small demo

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

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)

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

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

13


ORGANISATION

•History

•Virtual Full Trace

•Processes organization

•Workload analysis

•Driver requirements

•Conclusions

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

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

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.

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)

....

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+)

19


CLIENT/SERVER architecture

20


CLIENTS/server architecture

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

22


CLIENTS / server architectureProcess

---------------

| |

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

23


Workload balanceProcess and Tracer---------------

| |

T_prog + T_core

Analyzer---------

| |T_ana

Analyzer---------

| |

T_filter

Driver---------

| |T_cond

Tracer---------

| |T_extract

Analyzer---------

| |

T_rebuild

Tracer----------------- | |T_ encode-et-com

Analyzer---------| |

T_decode

==================================================

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)

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

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

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)

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

29


Thank you!

1 Pierre Deransart WLPE 061 On Using Tracer Driver for External Dynamic Process Observation Pierre...

Documents

Transcript of 1 Pierre Deransart WLPE 061 On Using Tracer Driver for External Dynamic Process Observation Pierre...