Set the PHC memory area size from a pref
Categories
(Core :: Memory Allocator, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox145 | --- | fixed |
People
(Reporter: pbone, Assigned: pbone)
References
(Blocks 1 open bug)
Details
Attachments
(5 files, 4 obsolete files)
| Assignee | ||
Comment 1•1 year ago
|
||
To allow the PHC arena size to be dynamic the reserved memory range may
be larger than the actual memory allocated by PHC. To keep the fast-path
as fast as possible this patch replaces the initial PtrKind() query with a
bounds check. The bounds check can be done without a lock. A later
step will determine the PtrKind.
-
Use a bounds check on the hot path for free, realloc and other
functions that take a pointer, before calling the corresponding PHC::
methods. -
The PHC method must assume it has a pointer that is in-bounds, but it
can determine the kind of the pointer with GetPtrKind(). -
Remove the Nothing PtrKind since it previously represented
out-of-bounds pointers. -
Add branch annotations on the hot paths.
| Assignee | ||
Comment 2•1 year ago
|
||
PHC's metadata size is defined at compile-time. To relax this to
runtime we need to use a different array implementation that stores the
size in a member variable, rather than a template parameter.
Refactor how metadata size is calculated since it must capture the size
of this array. Separate methods like FragmentationBytes() and
AllocationBytes() have been merged to get a consistent read by taking
the lock only once.
| Assignee | ||
Comment 3•1 year ago
|
||
The size of PHC's allocation area is now set when the metadata is
created. The kNumAllocPages symbol is removed, instead a new
NumAllocPages() function will return the length of the AllocInfo array.
The array is protected by the PHC lock so now getting the true size
of the PHC area (rather than the virtual memory reservation that it's
inside) can only be done while holding the lock. Checking the index of
an allocation during free() against the upper bound is now down after
taking the lock.
| Assignee | ||
Comment 4•1 year ago
|
||
PHC uses dynamic memory allocation* and so initialising it after
mozjemalloc makes sense, the easiest way to do this is to call it late
in mozjemalloc's initialisation.
*: it always has used dynamic memory, these patches add one additional
allocation. So this change isn't really necessary.
| Assignee | ||
Comment 5•1 year ago
|
||
Updated•1 year ago
|
| Assignee | ||
Comment 6•1 year ago
|
||
This allows expanding the size of memory area used by PHC, but not
shrinking it.
| Assignee | ||
Comment 7•1 year ago
|
||
| Assignee | ||
Comment 8•1 year ago
|
||
| Assignee | ||
Comment 9•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 10•1 year ago
|
||
Comment on attachment 9496683 [details]
WIP: Bug 1867191 - pt 4. Initialise PHC from mozjemalloc
Revision D254945 was moved to bug 1974931. Setting attachment 9496683 [details] to obsolete.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 11•1 year ago
|
||
Comment on attachment 9497599 [details]
Bug 1867191 - pt 7. Fix a misspelt variable name r=glandium
Revision D255489 was moved to bug 1975689. Setting attachment 9497599 [details] to obsolete.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 12•10 months ago
|
||
Comment 13•10 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/cae1ad7408cb
https://hg.mozilla.org/mozilla-central/rev/15dee2d249b6
https://hg.mozilla.org/mozilla-central/rev/4511e10cb420
https://hg.mozilla.org/mozilla-central/rev/6d53420157be
https://hg.mozilla.org/mozilla-central/rev/cd9cb17868e7
Updated•9 months ago
|
Description
•