With page size limited to 4KiB and the quantum-wide class covering the
range from 512 bytes to 4KiB, the sub-page size class is unused and can
be removed.
Differential Revision: https://phabricator.services.mozilla.com/D259220
With page size limited to 4KiB and the quantum-wide class covering the
range from 512 bytes to 4KiB, the sub-page size class is unused and can
be removed.
Differential Revision: https://phabricator.services.mozilla.com/D259220
MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
This memory was previously measured as part of committed memory. However
depending on the OS it will often not be committed. It's more accurate to
count it separately as part of mozjemalloc's cache of unused pages.
This patch adds counters for both fresh and madvised memory and no-longer
counts either as "committed" as it previously did.
This has the side effect of changing decisions based on the size of this
cache such as when to purge memory.
Differential Revision: https://phabricator.services.mozilla.com/D200415
jemalloc_stats takes an array for its second argument. It expects this
array to have enough space for all the bins, previously the maximum was set
as a magic number. To make it dependent on the configured bins this patch
replaces the compile-time constant with a function.
Differential Revision: https://phabricator.services.mozilla.com/D127761
isspace requires data in libc to be initialised. If we're parsing
/proc/smaps before libc has initialised we need to provide our own
implementation.
Differential Revision: https://phabricator.services.mozilla.com/D116338
Previously the id for a new arena was just a counter that increased by one
every time. For hardening purposes, we want to make private arenas use a secure
random ID, so an attacker will have a more difficult time finding the memory
they are looking for.
Differential Revision: https://phabricator.services.mozilla.com/D10158
Previously the id for a new arena was just a counter that increased by one
every time. For hardening purposes, we want to make the new counter a secure
random ID, so an attacker will have a more difficult time finding the memory
they are looking for.
Differential Revision: https://phabricator.services.mozilla.com/D10158
While jemalloc_stats is not actively doing anything, it can be
cumbersome to not have it count as an operation, because the operation
count shown on jemalloc_stats doesn't match the line number in the input
replay log, and the offset grows as the number of jemalloc_stats
operations grows.
While here, also update a comment about the replay log format.
It adds an uncompressible and noticeable time overhead to replaying
logs, even when one is not interested in measuring RSS. This has caused
me to clear the method body on multiple occasions.
If necessary, it is possible to enable zero or junk at the allocator
level for the same effect.
SRWLock is more lightweight than CriticalSection, but is only available
on Windows Vista and more. So until we actually dropped support Windows
XP, we had to use CriticalSection.
Now that all supported Windows versions do have SRWLock, this is a
switch we can make, and not only because SRWLock is more lightweight,
but because it can be statically initialized like on other platforms,
allowing to use the same initialization code as on other platforms,
and removing the requirement for a DllMain, which in turn can allow
to statically link mozjemalloc in some cases, instead of requiring a
shared library (DllMain only works on shared libraries), or manually
call the initialization function soon enough.
There is a downside, though: SRWLock, as opposed to CriticalSection, is
not fair, meaning it can have thread scheduling implications, and can
theoretically increase latency on some threads. However, it is the
default used by Rust Mutex, meaning it's at least good enough there.
Let's see how things go with this.
Those macros are one more thing that needs to be added when the
mozjemalloc API surface is increased, but after bug 1399350, nothing
actually needs them, so remove them.
Paul Bone