When forcing the nursery to shrink with gcparam() it doesn't shrink fast enough
Categories
(Core :: JavaScript: GC, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox71 | --- | fixed |
People
(Reporter: pbone, Assigned: pbone)
References
Details
Attachments
(8 files)
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review |
Maximum nursery size is sometimes counted in chunks rather than bytes. This can lead to a case where the caller expects the nursery to shrink because they changed the
maxNurseryBytes parameter to shrink it, but the nursery shrinks to only 512KB when the maximum is smaller.
| Assignee | ||
Comment 1•6 years ago
|
||
Nursery::exists() behaved exactly the same as Nursery::isEnabled() so use
the latter.
| Assignee | ||
Comment 2•6 years ago
|
||
We used to calculate the nursery's maximum size in chunks, and track the
maximum number of chunks permitted. This could lead to some unexpected
behaviour with a larger nursery than requested. Calculating it in bytes is
simpler, avoids this problem, and is more in-line with other calculations.
Depends on D39280
| Assignee | ||
Comment 3•6 years ago
|
||
Depends on D39281
| Assignee | ||
Comment 4•6 years ago
|
||
Depends on D39282
| Assignee | ||
Comment 5•6 years ago
|
||
The new variable, 'newMinNurseryBytes' is more in-line with the other
'newMaxNurseryBytes'.
Depends on D39283
| Assignee | ||
Comment 6•6 years ago
|
||
This method & the chunkCountLimit_ variable are unnecessary. The maximum
permitted nursery size is tracked in the GCSchedulingTunables class.
Depends on D39284
Comment 7•6 years ago
|
||
(In reply to Paul Bone [:pbone] from comment #0)
Not directly related to any of the patches: can you add a test case for this?
| Assignee | ||
Comment 8•6 years ago
|
||
(In reply to Jon Coppeard (:jonco) from comment #7)
(In reply to Paul Bone [:pbone] from comment #0)
Not directly related to any of the patches: can you add a test case for this?
It's not convenient. we'd need to add a new runtime parameter to query the current nursery size. I don't think its worth while to add the parameter just for a test. but maybe we want the parameter anyway? What do you think?
| Assignee | ||
Comment 9•6 years ago
|
||
(In reply to Paul Bone [:pbone] from comment #8)
(In reply to Jon Coppeard (:jonco) from comment #7)
(In reply to Paul Bone [:pbone] from comment #0)
Not directly related to any of the patches: can you add a test case for this?It's not convenient. we'd need to add a new runtime parameter to query the current nursery size. I don't think its worth while to add the parameter just for a test. but maybe we want the parameter anyway? What do you think?
If we did add a new parameter we could use it to write a test case for Bug 1388701 also.
| Assignee | ||
Comment 10•6 years ago
|
||
Depends on D39285
Comment 11•6 years ago
|
||
(In reply to Paul Bone [:pbone] from comment #8)
It's not convenient. we'd need to add a new runtime parameter to query the current nursery size.
We have the JSGC_BYTES parameter for heap size, so having one for nursery size too makes sense I think.
Can you add this and add tests that the nursery resizes correctly when the size parameters are changed?
| Assignee | ||
Comment 12•6 years ago
|
||
Depends on D39473
Comment 13•6 years ago
|
||
Comment 14•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/251f98554914
https://hg.mozilla.org/mozilla-central/rev/7b6e6a8c7bec
https://hg.mozilla.org/mozilla-central/rev/5c978eb8f1af
https://hg.mozilla.org/mozilla-central/rev/bb6a6819da31
https://hg.mozilla.org/mozilla-central/rev/cd9d586620b2
https://hg.mozilla.org/mozilla-central/rev/ae8f7739a47a
https://hg.mozilla.org/mozilla-central/rev/7ec72ad52389
https://hg.mozilla.org/mozilla-central/rev/d681969e4480
Comment 15•6 years ago
|
||
Paul, since these changes landed Bug 1567793 started perma-failling: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Crunnable&searchStr=os%2Cx%2C10.14%2Cshippable%2Copt%2Cmochitests%2Ctest-macosx1014-64-shippable%2Fopt-mochitest-devtools-webreplay-e10s%2Cm%28dt-wr%29&fromchange=99898d62af446cb6cff61223ae64e2b7e8ce4a61&tochange=a2cd6653f8569267b6e807a9e038c4174a110a07&selectedJob=259890155
Could you please take a look at it?
Comment 16•6 years ago
|
||
Comment 17•6 years ago
|
||
Comment 18•6 years ago
•
|
||
https://hg.mozilla.org/mozilla-central/rev/d9ab4193c7986173aecc80e7a68d7430024f4bf3
https://hg.mozilla.org/mozilla-central/rev/8ac0a35be0d35f9f5aba38ed841cb3d03a2ae3c8
| Assignee | ||
Updated•6 years ago
|
Comment 19•6 years ago
|
||
Comment 20•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/11042db2e05e
https://hg.mozilla.org/mozilla-central/rev/5d5db176ff49
https://hg.mozilla.org/mozilla-central/rev/8aa6b94125f3
https://hg.mozilla.org/mozilla-central/rev/f086a9bc71b6
https://hg.mozilla.org/mozilla-central/rev/e31e7762b04b
https://hg.mozilla.org/mozilla-central/rev/e7596cc41562
https://hg.mozilla.org/mozilla-central/rev/de7e00f6cc24
https://hg.mozilla.org/mozilla-central/rev/1d2a2360d4df
Description
•