debugging interfaces

Brendan Eich brendan at mozilla.org
Thu Aug 13 12:30:42 PDT 2009


To beat Allen to the re-sending punch (I hope), here's a reply-all I  
wrote without noticing the message to which I was replying had gone to  
es5-discuss not es-discuss (where it belonged).

To add a bit more detail, the closure optimizations in Firefox 3.5 do  
indeed cause some debugger stress. Imagine you can break in an  
optimized closure that was "flat" -- all the upvars it used were write- 
once and written before it was computed, so were copied into slots of  
the closure itself. The debugger driver might mutated such an upvar  
behind the back of the optimizer. We don't try to regenerate code to  
deoptimize on demand here -- instead we throw an exception if the  
debugger gets access to such a closure via a path that the compiler  
could not statically analyze.

This is sub-optimal, i.e., a bug in our debugger interface. Fixing it  
is a challenge. But we don't want to spread the a priori "compile with  
-g" meme, so we'll probably fix it soon.

/be

On Aug 13, 2009, at 11:33 AM, David-Sarah Hopwood wrote:

> Jordan Osete wrote:
>> Then, if we accept the idea of keeping only a reference to the  
>> objects
>> until information about them is explicitly requested, couldn't we  
>> do the
>> same things for the variables and arguments objects ?
>
> Keeping a reference to these would interfere with the use of optimized
> calling conventions where arguments are only stored in machine  
> registers
> and never reified (when 'arguments' is not referred to). Similarly for
> variable frames, which need not be reified unless they are captured  
> by a
> closure.

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.

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.

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

/be

_______________________________________________
es5-discuss mailing list
es5-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es5-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090813/fcd8f0f6/attachment-0001.html>


More information about the es-discuss mailing list