String deduplication is complicated and slow
Categories
(Core :: JavaScript Engine, task, P1)
Tracking
()
People
(Reporter: sfink, Assigned: sfink, NeedInfo)
References
(Blocks 3 open bugs)
Details
Attachments
(1 file, 1 obsolete file)
Bug 1895628 was a decent simplification without touching the underlying algorithm. But now that chains of dependent strings are even less likely than they were, and the chains that are possible are constrained in terms of which heap they're in (nursery vs tenured), I think this can all move to a single-pass algorithm.
Assignee | ||
Comment 1•21 days ago
|
||
I wasn't able to prove that it is never possible to have a chain ND1 -> TD2 -> NL3, where ND1 is a nursery dependent string, TD2 is a tenured dependent string, and NL3 is a nursery (non-dependent) linear string. But given that I haven't come up with a way to create that situation without cheating with a test function, I decided that it's good enough if that does a fallible allocation (with an oomUnsafe crash) during minor GC in the unlikely or impossible event that it actually happens.
I also added the testing function that allows it to happen anyway, just in case, so that this fallback code path is executed. To hit it, you need a dependent string in the nursery whose chain of bases goes through the tenured heap but ends up back in the nursery. Even then, it won't be a problem if the base string hasn't been promoted yet. These are precisely the cases where a deduplicated (or tenured-to-atom) base string moves its character data, but there's no way for nursery strings that depend on it to know what the original pointer was.
Assignee | ||
Comment 2•21 days ago
|
||
- Remove order-dependence between dependent strings and their bases by force-promoting their root base strings rather than using separate fixup phases (and different fixups for nursery and tenured strings) to adjust things after everything live is guaranteed to be promoted.
- Force-promotion is a recursive call, but it is guaranteed to bottom out immediately because root bases are never themselves dependent strings.
- Remove the aforementioned fixup phases (the nursery one still exists, but for recursing through ropes only)
This depends on dependent strings and root base strings being disjoint sets: while a dependent string's base can itself be a dependent string, the root base will never be. This is safe; it is the way it has always been.
Note that this patch introduces a theoretical bug that requires the full two-pass machinery to fix, but is at least rare and very possibly impossible to encounter in practice. The following patch will fix it.
Updated•21 days ago
|
Assignee | ||
Comment 3•21 days ago
|
||
Updated•15 days ago
|
Comment 5•1 day ago
|
||
Backed out for causing spidermonkey bustages in Tenuring.cpp.
- Backout link
- Push with failures
- Failure Log
- Failure line: Assertion failure: nursery_.inCollectedRegion(str), at /builds/worker/checkouts/gecko/js/src/gc/Tenuring.cpp:156
Comment 6•1 day ago
|
||
Backed out in addition to another changeset
Backout link: https://hg-edge.mozilla.org/integration/autoland/rev/bdc4e3df9b0b39caa628026d4ff80e16d2124a74
Updated•7 hours ago
|
Updated•7 hours ago
|
Assignee | ||
Comment 7•7 hours ago
|
||
I fixed the bug that caused the backout, then merged the two patches together (because the tests will fail with just the first applied), then fought moz-phab because it wouldn't accept the updated patch whether I used jj or git. Finally imported it into mercurial, and Phabricator accepted that. I still have no idea what's going on with that.
Hopefully it will stick now.
Description
•