[m-dev.] collect

[Erwan Jahier]

Hi.

For a few months now , I am working on monitoring of Mercury programs (as well
as test coverage). Seing the last mail of Zoltan, I think it is more than the
time to tell you a little about that.

I had paper accepted in a french conference (available at
http://www.irisa.fr/EXTERNE/projet/lande/jahier/jahier_jfplc99.ps but
unfortunenately, it is in French...) that is standing up for the following
idea: Runtime analysis (debugging, monitoring, profiling, test coverage,
invariant detection, ...) are implemented via ad hoc instrumentations. But all
the information needed by such dynamic analysis are in fact available in the
trace (that generally gives a fine grained image of the execution). So I've
shown how a variety of such dynamic analysis can implemented with Opium-M; 4
different monitors and how to perform two different kind of test coverage. Each
of them only required a few dozens of lines of Opium-M code. Hence any user
would be able to write such monitors (or any variation of existing monitors
that exactly fits to their needs).

The main advantages of this approach are :
- the simplicity of use (any user can get the monitor he needs),
- the flexibility,
- the synergy between tools.

The main drawback is of course efficiency, due in particular to socket traffic
and context switches between the debugger and the debuggee. For an execution of
several millions of events, a monitor that simply counts calls would still
require millions of communications between the 2 processes, and thus slow down 
the execution by a few order of magnitudes...

			       	-o-

That is the reason why I am currently designing and implementing a primitive
(that we called `collect', but I'm not absolutely happy with that name...) that
would allow to optimize that approach. This primitive avoid all the
communications between Opium-M and debbugee by analyzing the whole program
execution in one pass. Of course, I want this primitive to allow the same
flexibility and the same ease of use as with the Opium-M approach.

The `collect' is described in more details in a article that I submitted 
recently and that is available at:
http://www.irisa.fr/EXTERNE/projet/lande/jahier/collect.ps

Of course, implementing monitors or performing test coverage rates would be 
still less efficient with `collect' than hacking inside the Mercury 
compiler as Zoltan is currently doing. What I am looking for is a good 
flexibility/efficiency compromise.

I did a few measurements (I did not try to optimize anything, maybe those 
timings could be better) on a 3 millions events execution :

A    B    C    D     E  
9s  32s  45s  47s   45s   

* A is the Mercury program executed off-line.

* B is the Mercury program executed under the control of the external debugger,
but doing nothing else than giving the hand back to the execution (it measures
the cost of the tracer).

* C is a monitor that count the number of calls (i.e. the number of call 
events).

* D is a monitor that count the number of events at each different port.

* E is a monitor that counts the number of events at each depth (i.e., the 
histogram experimental command of Zoltan).

-- 
R1.


--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------