debugging interfaces

Patrick Mueller pmuellr at yahoo.com
Thu Aug 13 06:49:50 PDT 2009


On Aug 13, 2009, at 3:38 AM, Christian Plesner Hansen wrote:

> Having recently implemented stack traces in v8 I can provide some
> input on this from an implementation perspective.
>
> We have pretty strict performance requirements so I did a lot of
> experimentation to see how much information could be collected without
> affecting performance noticeably.  The result was that it was feasible
> to collect the value of this, the function being called, and the
> current position within the function.  Collecting arguments would have
> been too expensive.  Collecting variables would have been much too
> expensive.

I can understand wanting to optimize stack trace generation for the  
case of your captureStackTrace() method, but for debugging purposes, I  
would think the performance wouldn't matter.

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.

The third seems less important right now.

For the first issue, existing plain old user-land runtime usage, there  
was an interesting thread in the webkit mailing list yesterday:

    http://thread.gmane.org/gmane.os.opendarwin.webkit.devel/9399/focus=9407

I guess there's no specification for how to get any source location  
information from an Error.  That would be nice to have, even without a  
captureStackTrace(), so that we don't need to have vendor-specific  
SPIs to do it.  Presumably something like a "source", "line" and  
"column" properties, all optional.  At least a common place for  
implementors to hang this type of information, if they have it.

Patrick Mueller - http://muellerware.org/



More information about the es-discuss mailing list