SpiderMonkey would benefit from having a lightweight, unified representation for call stack snapshots. At present we capture the call stack when creating objects of the
Error class, but there are many other uses:
- Profiling: Profilers could accumulate a collection of stack snapshots, with count metadata. A precise call profiler or an object allocation profiler might use this.
- Tracking event handlers: Functions like
setInternalthat register event handlers could snapshot the stack when a new event handler is established. Then, developer tools and error messages could present that snapshot as context when the event handler actually runs.
eval<code> or the <code>Functionconstructor, or by inserting dynamically generated
- C++, so that the browser implementation (say, the DOM implementation, registering timeout and internal handlers) can record snapshots at interesting points efficiently.
Frameworks may want to elide their implementation details for clarity, so the snapshot API should let code flag certain frames to be presented by developer tools in a simplified form. For example, when a
jQuery event handler fires, developer tools should present a simplied, legible description of what sort of jQuery event it is, and where the application called the jQuery method to register the handler, rather than simply showing stack frames executing functions internal to jQuery.
This work is just getting started; no bugs have been filed for it yet.