jor at joozt.net
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 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
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 ?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss