debugging interfaces

Christian Plesner Hansen christian.plesner.hansen at
Thu Aug 13 13:13:45 PDT 2009

> Right. Or, even moreso, if possible -- there may be no variable object
> reified in an implementation that optimizes harder. ES1-5 take pains to
> avoid any reference to such an object escaping. Firefox 3.5 optimizes
> various closure cases including non-escaping Algol-like procedures (using a
> display) and closures capturing write-once variables whose initialisers
> dominate the closure ("flat closures", what Chez Scheme calls "display
> closures"). Assignment conversion (a la Chez Scheme) is being explored.

Exactly.  In v8 the variable and arguments objects are usually not
reified, the variables are stored on the stack or in registers, and
sorting out which source-level variables they correspond to is fairly

> 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.

In v8 we have a strict "no modes" philosophy for similar reasons.

> I like Christian's proposal, FWIW. We should see about other VMs
> implementing it.

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.

-- Christian

More information about the es-discuss mailing list