Re: What debugger breakpoint features would you like?

[Rob Browning]

Neil Jerram <address@hidden> writes:

> I still don't see the problem.  Suppose you're collecting entry
> count and total time for functions in a program, putting the results
> into a hash table that is keyed by a list of cars of expressions
> leading to that function call.  [in reverse order]

Hmm.  I wasn't thinking about keeping the list of cars.  When I played
around with this before, I had just keyed the table on function
pointers, so the db was flat.

  i.e. function-obj -> accumulated time

Part of my problem was that I wasn't quite clear from the docs exactly
what the enter/exit/apply handlers were trapping.  i.e. what exactly
does a frame represent.  What's the difference between entering and
applying, etc., though some of this I figured out via experimentation.

But one of the reasons for the flat, very lightweight, data table is
that I didn't want the actual data stored by the profiler to have too
big an impact on the program's behavior wrt memory locality,
allocation, gc, etc.  I suspect memory locality and cache issues can
be a killer when your interpreter is coded well enough to take those
into account. 

All that said, I'm not sure the rest of the quick-hack precise
profiler I tried to whip up actually respected my concerns :>

> This isn't quite right, because the keys for calls in tail position
> are collapsed in the same way as tail call frames.  So let's say
> that, whenever tail? is true, we also push the symbol 'tail? onto
> the key stack.  Then the rule for the exit-frame handler is to keep
> popping keys until it sees something other than 'tail?:

Actually I think perhaps this is the problem I was worried about.
Imagine you've implemented an event loop using tail-recursion.  In the
non-profiling case, this is fine and you can run forever.  However,
unless I'm misunderstanding, in the profiling case, the key stack will
grow without bound, and even in less aggravated cases, the growth of
the key stack will still skew your results, possibly seriously.

As I recall, a few other tricks I considered during the (somewhat)
brief period when I was thinking about this wouldn't work either if
mutual tail recursion was involved.  Of course, I didn't think *super*
hard about any of this.  I was in somewhat a hurry, and after
identifying these concerns, I decided to just switch to implementing
the statistical profiler.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD