Cleanup existing JIT-code preservation code
Categories
(Core :: JavaScript: GC, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox136 | --- | fixed |
People
(Reporter: mgaudet, Assigned: mgaudet)
References
(Blocks 1 open bug)
Details
Attachments
(12 files, 2 obsolete files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
This bug is for tracking some non-functional changes to how JIT code is managed by GC (renaming, documentation comments etc)
Assignee | ||
Comment 1•2 months ago
|
||
Updated•2 months ago
|
Assignee | ||
Comment 2•2 months ago
|
||
There -is- a semantic change here. In GCRuntime::maybeCallGCCallback we save and restore
the gcOptions, lest we re-enter GC. This means there are a couple of possible changes
in behaviour from this change (and I'm honestly not sure which happens here, or
if ultimately this matters at all):
-
The first option is that as a result of this, a nested GC triggered by a GC
callback which would have previouly done a 'cleanupEverything' GC no longer
does, as the nested GC may have a different GCOptions. -
The second option is that nested GC could have accidentally been clearing
the cleanupEverything field, and now it no longer does. As a result we do
-more- cleanupEverything GC now than we did before.
Assignee | ||
Comment 3•2 months ago
|
||
Assignee | ||
Comment 4•2 months ago
|
||
There -is- a semantic change here. In GCRuntime::maybeCallGCCallback we save and restore
the gcOptions, lest we re-enter GC. This means there are a couple of possible changes
in behaviour from this change (and I'm honestly not sure which happens here, or
if ultimately this matters at all):
-
The first option is that as a result of this, a nested GC triggered by a GC
callback which would have previouly done a 'cleanupEverything' GC no longer
does, as the nested GC may have a different GCOptions. -
The second option is that nested GC could have accidentally been clearing
the cleanupEverything field, and now it no longer does. As a result we do
-more- cleanupEverything GC now than we did before.
Assignee | ||
Comment 5•2 months ago
|
||
Assignee | ||
Comment 6•2 months ago
|
||
Assignee | ||
Comment 7•2 months ago
|
||
Assignee | ||
Comment 8•2 months ago
|
||
Here we should just straight to forceDiscardJitCode.
Assignee | ||
Comment 9•2 months ago
|
||
Clarify this functions name
Assignee | ||
Comment 10•2 months ago
|
||
Assignee | ||
Comment 11•2 months ago
|
||
No caller ever provides any non-default.
Assignee | ||
Comment 12•2 months ago
|
||
Assignee | ||
Comment 13•2 months ago
|
||
Assignee | ||
Comment 14•2 months ago
|
||
Updated•2 months ago
|
Updated•2 months ago
|
Updated•8 days ago
|
Comment 15•7 days ago
|
||
Comment 16•7 days ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/712aad5a0b58
https://hg.mozilla.org/mozilla-central/rev/9ff939988c61
https://hg.mozilla.org/mozilla-central/rev/de793cbd8de5
https://hg.mozilla.org/mozilla-central/rev/e194475daa2e
https://hg.mozilla.org/mozilla-central/rev/7dc64ac5009a
https://hg.mozilla.org/mozilla-central/rev/6ba7346640ee
https://hg.mozilla.org/mozilla-central/rev/8405785b43b7
https://hg.mozilla.org/mozilla-central/rev/9c56922c616b
https://hg.mozilla.org/mozilla-central/rev/a773e246306b
https://hg.mozilla.org/mozilla-central/rev/efb91e901151
https://hg.mozilla.org/mozilla-central/rev/44cadd43898a
Description
•