rossberg at google.com
Fri Sep 16 01:55:31 PDT 2011
On 16 September 2011 02:12, Mike Shaver <mike.shaver at gmail.com> wrote:
> On Thu, Sep 15, 2011 at 9:02 AM, Andreas Rossberg <rossberg at google.com> wrote:
>> On 14 September 2011 00:00, Brendan Eich <brendan at mozilla.com> wrote:
>>> So, static+dynamic. The static side has some powerful algorithms to bring to bear. Dynamic is necessary due to eval and kin, and gives strictly more information (and more relevant information!).
>> Nitpick: I believe you are mistaken about the "strictly more" bit.
>> There is information that _only_ static analysis can derive. Consider
>> e.g. aliasing or escape analysis, or other kinds of global properties.
> There are systems that handle escape analysis cases via write
> barriers, no? Alias detection (or more importantly non-alias
> determinations) seem amenable to the assume-and-guard model used for
> PICs and trace selection and other code specialization patterns seen
> all over modern JS engines.
Being able to detect when a condition is violated is not equivalent to
knowing that it always holds.
Take the property access example. You want to eliminate the extra
check. For that you have to know that the typecheck would _never_ fail
at this point. You use type inference to find that out, a static
In general, whenever the correctness of an optimization or code
transformation depends on a non-trivial _invariant_, you have to prove
that this invariant holds. You can only do that statically, because it
implies a quantification over all possible executions. No amount of
dynamic checking can give you that.
(Of course, you can often do something else instead that involves
dynamic checks, but then you are in fact doing a _different_
optimization. Property access is a good example. Stack-allocating
local variables is another one, where you need escape analysis.)
More information about the es-discuss