Bug 166989
| Summary: | We could probably remove the write barrier at the end Structure::flattenDictionaryStructure | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Saam Barati <saam> |
| Component: | JavaScriptCore | Assignee: | Saam Barati <saam> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | benjamin, fpizlo, ggaren, gskachkov, jfbastien, keith_miller, mark.lam, msaboff, oliver, ticaiolima, ysuzuki |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 166960 | ||
| Bug Blocks: | |||
Saam Barati
After https://bugs.webkit.org/show_bug.cgi?id=166960, we'll have a way that rescans after races are detected.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Saam Barati
I actually think this is necessary, imagine you're in the middle of flatten, and you have a butterfly that contains 3 valid properties, and a bunch of empty space, like this:
{a, ..., b, ..., c, ...}
and we want to end up with our property storage looking like this while in the middle of this loop:
```
// Copies in our values to their compacted locations.
for (unsigned i = 0; i < propertyCount; i++)
object->putDirect(vm, offsetForPropertyNumber(i, m_inlineCapacity), values[i]);
```
{..., a, ..., a, c}
And imagine if we scanned the property storage at that point, we'd end not scanning for "b". Therefore, I think this barrier is indeed needed.
Saam Barati
(In reply to Saam Barati from comment #1)
> I actually think this is necessary, imagine you're in the middle of flatten,
> and you have a butterfly that contains 3 valid properties, and a bunch of
> empty space, like this:
> {a, ..., b, ..., c, ...}
>
> and we want to end up with our property storage looking like this while in
> the middle of this loop:
> ```
> // Copies in our values to their compacted locations.
> for (unsigned i = 0; i < propertyCount; i++)
> object->putDirect(vm, offsetForPropertyNumber(i,
> m_inlineCapacity), values[i]);
> ```
> {..., a, ..., a, c}
>
> And imagine if we scanned the property storage at that point, we'd end not
> scanning for "b". Therefore, I think this barrier is indeed needed.
The reason we may not detect this as a race is like so:
Imagine the collector did this:
ReadStructureEarly
ReadLastOffsetEarly
ReadButterfly
ReadStructureLate
ReadLastOffsetLate
then, the mutator does
flattenDictionaryStructure
mutator gets into the middle of the above loop
collector scans property storage
We won't detect a race here, but we need to rescan.