debugging interfaces

Mark S. Miller erights at google.com
Thu Aug 13 08:23:37 PDT 2009


On Thu, Aug 13, 2009 at 6:49 AM, Patrick Mueller<pmuellr at yahoo.com> wrote:
> There are a couple of different scenarios I can imagine you might want stack
> trace information, with differing expectations of performance and detail
> available:
>
> - runtime usage, as the example of captureStackTrace() - should be highly
> optimized and may not contain full detail
>
> - debugger usage, where the debugger has actually paused the current thread
> of execution, and so performance shouldn't be an issue (relative to
> performance of the current thread, which is paused), and should contain as
> much detail as is feasible.
>
> - performance tool usage - something between the two - think something like
> a profiler which might need more detail than captureStackTrace() but less
> than the debugger, and would also have respective performance requirements
> between the two as well.

A good list. Another is to accumulate traces for post-mortem
debugging, as in
<http://www.hpl.hp.com/techreports/2009/HPL-2009-78.html>,
<http://wiki.erights.org/wiki/Causeway>. This becomes especially
important for debugging systems consisting of multiple clients and
servers. From a performance perspective, this is probably in the same
category as performance tools.


-- 
    Cheers,
    --MarkM


More information about the es-discuss mailing list