Bug 159537 - REGRESSION(184445): Need to insert a StoreBarrier when we don't know child's epoch
Summary: REGRESSION(184445): Need to insert a StoreBarrier when we don't know child's ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Major
Assignee: Michael Saboff
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2016-07-07 16:49 PDT by Michael Saboff
Modified: 2016-07-07 20:48 PDT (History)
4 users (show)

See Also:


Attachments
Patch (3.78 KB, patch)
2016-07-07 19:58 PDT, Michael Saboff
benjamin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Saboff 2016-07-07 16:49:31 PDT
In StoreBarrierInsertionPhase::considerBarrier(Edge base, Edge child), there is the following comment and code:

        // Something we watch out for here is that the null epoch is a catch-all for objects
        // allocated before we did any epoch tracking. Two objects being in the null epoch
        // means that we don't know their epoch relationship.
        if (!!base->epoch() && base->epoch() >= child->epoch()) {
            if (verbose)
                dataLog("            Rejecting because of epoch ordering.\n");
            return;
        }
The test doesn't check that the child's epoch is null and therefore we won't insert a barrier for the case where we allocate the base object, but don't know when the child object was allocated.

<rdar://problem/23438751>
Comment 1 Michael Saboff 2016-07-07 19:58:54 PDT
Created attachment 283101 [details]
Patch
Comment 2 Michael Saboff 2016-07-07 20:48:36 PDT
Committed r202955: <http://trac.webkit.org/changeset/202955>