Javascript:SpiderMonkey:StackSnapshots

	THIS PAGE IS OBSOLETE
	This article is in parts, or in its entirety, outdated. Hence, the information presented on this page may be incorrect, and should be treated with due caution. Visit SpiderMonkey.dev for more up to date information.

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 setTimeout and setInternal that 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.
• Dynamic script addition: The JavaScript and DOM implementations could snapshot the stack whenever new JavaScript code is introduced to the system, whether by calling functions like eval<code> or the <code>Function constructor, or by inserting dynamically generated <script> elements. Then, developer tools could present these snapshots to explain how a particular piece of JavaScript code originated.

Stack snapshots should have both a C++ and a JavaScript API:

• C++, so that the browser implementation (say, the DOM implementation, registering timeout and internal handlers) can record snapshots at interesting points efficiently.
• JavaScript, so that content libraries that introduce their own abstractions for asynchronous execution (like jQuery and Ember.js) could provide the same debugging benefits to their users that the browser's built-in facilities do. With some coordination, Firefox's developer tools could display stack snapshots captured by content libraries.

Internally, stack snapshots should cross chrome/content privilege boundaries, capturing the complete chain of causality. Then, the JavaScript API should consider the privileges of its caller when presenting the frames of a given snapshot, revealing only those frames that the caller is permitted to know about.

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.