Bug 159537

Summary: REGRESSION(184445): Need to insert a StoreBarrier when we don't know child's epoch
Product: WebKit Reporter: Michael Saboff <msaboff>
Component: JavaScriptCoreAssignee: Michael Saboff <msaboff>
Status: RESOLVED FIXED    
Severity: Major CC: commit-queue, keith_miller, mark.lam, saam
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch benjamin: review+

Michael Saboff
Reported 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>
Attachments
Patch (3.78 KB, patch)
2016-07-07 19:58 PDT, Michael Saboff
benjamin: review+
Michael Saboff
Comment 1 2016-07-07 19:58:54 PDT
Michael Saboff
Comment 2 2016-07-07 20:48:36 PDT
Note You need to log in before you can comment on or make changes to this bug.