debugging interfaces

Jordan Osete jor at
Sat Aug 15 17:09:35 PDT 2009

Patrick Mueller wrote:
> 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.

Mark S. Miller wrote:
> On Thu, Aug 13, 2009 at 6:49 AM, Patrick Mueller<pmuellr at> 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
Agreed, again.

Brendan Eich wrote:
> If we impose a model where you have to "compile with -g" to get 
> first-class stack inspection, otherwise you get nothing, developers 
> will always turn on the deoptimizing debugger-friendly option, after 
> being burned by missing the chance to diagnose a bug /in 
> flagrante/ because they were running in optimized mode.

Now if I understood it correctly, what makes all this information 
collection performance hungry is really about the arguments and 
variables. Everything else, from the current function name and this 
object, to the file name and in-code localization could be obtained with 
"acceptable" performance". (Please correct me if I am wrong. In 
particular, to which level of detail can we get for "in-code 
localization" without risking serious slowdown ? File name ? Function ? 
Line number ? Instruction boundaries ?)

Also storing references to arguments or variables for later use is 
impractical, as it would slow down execution dramatically. So the main 
issue about the potential inclusion of variable and arguments 
information is that when we still have got it, we don't know if it will 
ever be used. Always including it means wasting performance dramatically 
(and is a potential nightmare for the engine developers, but I'm sure 
they could manage it ;) ), but never including it means that we throw 
away information that could potentially be useful...

Now, how about letting the user ask for that information only at one 
point - when it is still here ? Or better: before.
It may seem foolish, but if we allow some kind of way to tell that we 
desperately need that information - for example in the try statement - 
then the engine can enter the try statement knowing that we will need it.

catch( e, fullStackInformation )   //notice the second parameter here

Now, by including a second parameter in the catch clause, the engine 
knows that, for this particular try statement, we need particularly 
precise information, even if it may be at the cost of speed. It becomes 
an opt-in, but a finely grained one - not like a global compile switch.
Of course, whether the second parameter is present or not, one can still 
use Error.captureStackTrace to get whatever information the engine can 
give him without performance penalties.

Brendan Eich wrote:
> I like Christian's proposal, FWIW. We should see about other VMs 
> implementing it.
Christian Plesner Hansen wrote:
> I considered an alternative to the Error.captureStackTrace API which
> was an Error.getStackTrace call that returned a StackTrace object,
> rather than a string, with a toString method that did the formatting.
> I didn't want to stray too far from the functionality in other
> browsers so I ended up not doing that but I still like that better
> than captureStackTrace.
Although I must admit I was slightly surprised with this syntax at 
first, I am starting to get used to it now, and I think I like it.
However I don't understand the part about returning a string. As I 
understood it, it returned a StackTrace object, pretty much like an 
array of stack frames.
Could you please give us more details about what Error.getStackTrace and 
Error.captureStackTrace exactly do ?


Jordan OSETE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list