Bug 94412 - The current state of the call frame should be taken into account in the DFG for both predictions and proofs
Summary: The current state of the call frame should be taken into account in the DFG f...
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Filip Pizlo
Depends on:
Blocks: 94205
  Show dependency treegraph
Reported: 2012-08-17 22:22 PDT by Filip Pizlo
Modified: 2012-08-19 15:03 PDT (History)
5 users (show)

See Also:

work in progress (31.41 KB, patch)
2012-08-17 22:40 PDT, Filip Pizlo
no flags Details | Formatted Diff | Diff
the patch (34.74 KB, patch)
2012-08-18 12:19 PDT, Filip Pizlo
ggaren: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Filip Pizlo 2012-08-17 22:22:01 PDT
As the CFA gets smarter, we're seeing situations where it "correctly" proves that the OSR entrypoint through which we're trying to enter cannot possibly execute. This occurs when you have code which, in its prologue, modifies some constant object and flips it to have a new structure:

o = constant;
o.f = thing; // create new field
loop { // osr entrpoint

o's structure at compile-time will be the structure after having created the new field.  Likely, that structure will be terminal, and so watchpointable.  Hence we will prove that o's future structure set contains only that structure.  But that means that 'o.f = thing' cannot possibly succeed every again, which is absolutely true - it can't.  Any future execution of that statement, so long as that statement is creating a new field and nothing more, will OSR exit immediately.  But then we go and prove our own demise, as it were: we prove that the OSR entrypoint is unreachable, since the code that preceded it cannot execute.

It's useful to leverage knowledge of what the future structure set of an object can be in the future.  We use this to do good optimizations, like structure watchpointing.  That necessarily implies leveraging the fact that an object's structure cannot time-travel into the past.  But in cases where the entrypoint into the function occurs at a point that is proven unreachable by this strategy, we should, instead of disabling entry, force the analysis to be just conservative enough to allow that entry to happen.
Comment 1 Filip Pizlo 2012-08-17 22:40:30 PDT
Created attachment 159262 [details]
work in progress
Comment 2 Filip Pizlo 2012-08-18 12:19:15 PDT
Created attachment 159263 [details]
the patch
Comment 3 Geoffrey Garen 2012-08-19 14:50:26 PDT
Comment on attachment 159263 [details]
the patch

R is me
Comment 4 Geoffrey Garen 2012-08-19 14:51:33 PDT
Comment on attachment 159263 [details]
the patch

R is me
Comment 5 Filip Pizlo 2012-08-19 15:03:05 PDT
Landed in http://trac.webkit.org/changeset/125982