[m-dev.] stack dump

[Tyson Dowd]

On 15-Sep-1998, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
> Zoltan Somogyi wrote:
> >
> > > 1) would it be easy to implement a primitive that retrieve the list of
> > > ancestors of the current predicate ? (I mean a primitive which go and
> > > look in an existing stack) Is this information always available ?
> > 
> > runtime/mercury_stack_trace.c has the primitives for this.
> > 
> > This information is always available in debug grade. In other grades,
> > the information may be missing for some modules, and when the stack trace
> > hits a predicate from such a module, it must stop while still incomplete.
> 
> In order to be able to always print such stack traces, you needed to
> make some information available in the memory more longer, rigth ?

You only need to keep information relating each label with the
number of stack slots used by the code, and the name of the label.

You might be thinking of typeinfo liveness, which is required for
execution tracing (to print variables) and for native GC (to garbage
collect variables).

> 
> I was wondering if you were able to estimate what was the cost of that:
> - in terms of execution speed ?
> - in terms of memory consumption ?

We have not benchmarked, but I would guess relatively small.

Basic stack layouts use a few words per label.  It is all static data in
most grades.  They use some hash tables that aren't initialized until
you need them.  Compared to the space used for execution tracing
(names of variables, locations at each trace point, etc), it isn't
much.

They don't really slow down execution speed at all
(there is a hypothesis that taking the addresses of the lables might
reduce the optimizations gcc can perform around that label, but it
it untested).

The typeinfo liveness does a bit more than this, and will occasionally
use stack slot longer than previously necessary, which can mean another
stack slot is needed.  I don't think it's particularly significant, but
detailed measurements haven't been made.

> - in terms of developement efforts ? (Tyson ?-)

For plain stack traces, it wasn't all that hard because it was an
afterthought while creating accurate GC data structures.

For typeinfo liveness, that hard part was understanding exactly what was
required.  It wasn't too hard to modify the compiler -- but testing it
and getting it to its current state probably took quite a bit of effort.

> 
> I am asking that because it possible to reconstruct that information
> quite easily at the debugger level (10 lines of opium programming +
> re-execute the program).
> 
> 
> ps: Is this information (the one to be able to dump stack trace all the
> time) used for something else ?

Yes.  Native GC needs it, and it's not feasible to re-execute the
program in order to garbage collect it ;-)

Almost the same information is required to do execution tracing anyway.

-- 
Those who would give up essential liberty to purchase a little temporary
safety deserve neither liberty nor safety.     - Benjamin Franklin

Tyson Dowd   <tyson at tyse.net>   http://tyse.net