debugging interfaces

David-Sarah Hopwood david-sarah at
Tue Aug 18 17:12:20 PDT 2009

Jordan Osete wrote:
> 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.
> try
> {
>    ...
> }
> catch( e, fullStackInformation )   //notice the second parameter here
> {
>    ...
> }

Since the body of the try statement can call arbitrary other code, this
doesn't help to decide which code should be compiled in a way that preserves
extra debugging information. Remember that if we compile code to do that,
it incurs overhead whether or not an exception actually occurs.

It would be possible to compile both optimized and deoptimized versions
of each function, and check in the optimized version whether it is in the
dynamic scope of such a 'try' block. (Actually, there's no need to restrict
it to 'try' blocks if doing that.) However, that would still add the
overhead of the check to the entry code for all optimized (and not inlined)
functions. I think it would be an overspecification to require any such

As Christian says, we might define a common interface for implementations
that do want to support this, but I don't think it requires changes to
language syntax. A 'runWithMoreDebugInfo(someFunction)' API would suffice.

David-Sarah Hopwood  ⚥

More information about the es-discuss mailing list