Relazified scripts should not revive without updating canonical function
Categories
(Core :: JavaScript Engine, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox72 | --- | fixed |
People
(Reporter: tcampbell, Assigned: tcampbell)
References
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
text/x-phabricator-request
|
Details |
While working on Bug 1589904 I stumbled on a preexisting issue where after relazification, but before the incremental-gc has swept a JSScript, we can revive it without making the canonical JSFunction non-lazy. This is a bug according to [1] and according to good sense.
This could be fixed in JSFunction::createScriptForLazilyInterpretedFunction, but we would also need to be careful that places accessing LazyScript::maybeScript() directly aren't breaking things too.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Here is a test case and an assert that matches the stated invariants.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
This fixes a bug where relazification during an incremental GC may lead
to a JSScript being revived. When this happens, it was possible that
only a function clone would be delazify and the JSFunction would remain
lazy. This breaks basic invariants of the system.
The fix is to only allow this revival on canonical functions. A
non-canonical function will then need to delazify the canonical function
first and invariants are preserved. The call to JSScript::setLazyScript
is also removed since it was being guarded by a release assert ensuring
the value was already correct.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
The fundamental issue is that at [1] we set a function to non-lazy without first ensuring the canonical function is non-lazy. Every other location we turn a JSFunction from lazy to non-lazy we are working on the canonical function.
Comment 5•5 years ago
|
||
bugherder |
Description
•