`mozilla::IsPowerOfTwo` is used in more code than the previous functions, so split
up the updates in three parts. This part updates non-SpiderMonkey code to use
`std::has_single_bit`. The next part updates SpiderMonkey code and the last part
finally removes `mozilla::IsPowerOfTwo`.
Differential Revision: https://phabricator.services.mozilla.com/D286320
This reverts commit eb884a9f65.
Revert "Bug 2020608 - Part 16: Use std::bit_ceil for RoundUpPow2. r=sergesanspaille"
This reverts commit 35a310aa8a.
Revert "Bug 2020608 - Part 15: Require unsigned integral types for CeilingLog2 and FindMostSignificantBit. r=sergesanspaille,nbp"
This reverts commit f682901ca2.
Revert "Bug 2020608 - Part 14: Remove mozilla::IsPowerOfTwo. r=sergesanspaille"
This reverts commit b998e4bd39.
Revert "Bug 2020608 - Part 13: Replace IsPowerOfTwo with std::has_single_bit in js/. r=sergesanspaille"
This reverts commit 00db5e1f32.
Revert "Bug 2020608 - Part 12: Replace IsPowerOfTwo with std::has_single_bit outside of js/. r=sergesanspaille,profiler-reviewers,win-reviewers,gstoll,canaltinova"
This reverts commit cec056f5d6.
Revert "Bug 2020608 - Part 11: Simplify PowerOfTwo. r=sergesanspaille,profiler-reviewers,canaltinova"
This reverts commit a2ee5b9053.
Revert "Bug 2020608 - Part 10: Prefer std::bit_width in MathAlgorithms.h. r=sergesanspaille"
This reverts commit 89d966bb97.
Revert "Bug 2020608 - Part 9: Prefer std::bit_width instead of std::countl_zero in js/src. r=sergesanspaille"
This reverts commit da9a43075a.
Revert "Bug 2020608 - Part 8: Replace CountTrailingZeroes with std::countr_zero. r=sergesanspaille"
This reverts commit d77ca273cb.
Revert "Bug 2020608 - Part 7: Replace CountLeadingZeroes32 with std::countl_zero or std::countl_one. r=sergesanspaille,nbp,profiler-reviewers,canaltinova"
This reverts commit 94929ae729.
Revert "Bug 2020608 - Part 6: Replace CountLeadingZeroes64 with std::countl_zero. r=sergesanspaille,profiler-reviewers,canaltinova"
This reverts commit 9b428168df.
Revert "Bug 2020608 - Part 5: Replace CountTrailingZeroes32 with std::countr_zero. r=sergesanspaille,manuel"
This reverts commit d3e77036b2.
Revert "Bug 2020608 - Part 4: Replace CountTrailingZeroes64 with std::countr_zero or std::countr_one. r=sergesanspaille"
This reverts commit 6a7bcee10e.
Revert "Bug 2020608 - Part 3: Replace CountPopulation32 with std::popcount. r=sergesanspaille"
This reverts commit e7b204177b.
Revert "Bug 2020608 - Part 2: Replace CountPopulation64 with std::popcount. r=sergesanspaille"
This reverts commit 1d6f98a622.
Revert "Bug 2020608 - Part 1: Add <bit> C++20 definitions to std.py. r=sergesanspaille"
This reverts commit 3ee4c6dcab.
`mozilla::IsPowerOfTwo` is used in more code than the previous functions, so split
up the updates in three parts. This part updates non-SpiderMonkey code to use
`std::has_single_bit`. The next part updates SpiderMonkey code and the last part
finally removes `mozilla::IsPowerOfTwo`.
Differential Revision: https://phabricator.services.mozilla.com/D286320
This should remap as read-only and use that address, because unmapping
allows the address to be used by anything else (causing intermittent
failure).
The other `LocalProtect` test was also bad, so I fixed that and a
few compiler warnings.
Differential Revision: https://phabricator.services.mozilla.com/D241865
This disarms a footgun in the FreezableMapping::Freeze API, which was
causing read-only mappings in the global stylesheet cache to fail. These
failures caused content processes to re-load the style sheets,
increasing memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D240928
This disarms a footgun in the FreezableMapping::Freeze API, which was
causing read-only mappings in the global stylesheet cache to fail. These
failures caused content processes to re-load the style sheets,
increasing memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D240928
This adds a new type, `SharedMemoryCursor`, as well as platform support
for mapping subregions of shared memory handles. This type will attempt
to map the entire shared memory region, and will back off on the size of
the region until it can successfully map a portion of the region to read
data from.
Ideally, this should help reduce the chances of encountering memory
fragmentation issues when sending large JS structured clone buffers over
IPC.
Differential Revision: https://phabricator.services.mozilla.com/D233116
This adds a new type, `SharedMemoryCursor`, as well as platform support
for mapping subregions of shared memory handles. This type will attempt
to map the entire shared memory region, and will back off on the size of
the region until it can successfully map a portion of the region to read
data from.
Ideally, this should help reduce the chances of encountering memory
fragmentation issues when sending large JS structured clone buffers over
IPC.
Differential Revision: https://phabricator.services.mozilla.com/D233116
This patch also uses `MFD_ALLOW_SEALING` unconditionally, even if we're
not planning to seal the memfd, because `MFD_NOEXEC_SEAL` implies it.
(We could re-add `F_SEAL_SEAL` explicitly in that case but I don't think
it makes a meaningful difference in our use cases.)
Differential Revision: https://phabricator.services.mozilla.com/D222575
This is useful for the following parts, as UniqueFileHandle is a cross-platform
type which can also be used to support transferring HANDLEs between processes.
This change requires fairly sweeping changes to existing callsites, which
previously did not require owning access to the handle types when transferring.
For the most part these changes were straightforward, but manual.
Differential Revision: https://phabricator.services.mozilla.com/D126564
This is useful for the following parts, as UniqueFileHandle is a cross-platform
type which can also be used to support transferring HANDLEs between processes.
This change requires fairly sweeping changes to existing callsites, which
previously did not require owning access to the handle types when transferring.
For the most part these changes were straightforward, but manual.
Differential Revision: https://phabricator.services.mozilla.com/D126564
This commit also allows `memfd_create` in the seccomp-bpf policy for all
process types.
`memfd_create` is an API added in Linux 3.17 (and adopted by FreeBSD
for the upcoming version 13) for creating anonymous shared memory
not connected to any filesystem. Supporting it means that sandboxed
child processes on Linux can create shared memory directly instead of
messaging a broker, which is unavoidably slower, and it should avoid
the problems we'd been seeing with overly small `/dev/shm` in container
environments (which were causing serious problems for using Firefox for
automated testing of frontend projects).
`memfd_create` also introduces the related operation of file seals:
irrevocably preventing types of modifications to a file. Unfortunately,
the most useful one, `F_SEAL_WRITE`, can't be relied on; see the large
comment in `SharedMemory:ReadOnlyCopy` for details. So we still use
the applicable seals as defense in depth, but read-only copies are
implemented on Linux by using procfs (and see the comments on the
`ReadOnlyCopy` function in `shared_memory_posix.cc` for the subtleties
there).
There's also a FreeBSD implementation, using `cap_rights_limit` for
read-only copies, if the build host is new enough to have the
`memfd_create` function.
The support code for Android, which doesn't support shm_open and can't
use the memfd backend because of issues with its SELinux policy (see bug
1670277), has been reorganized to reflect that we'll always use its own
API, ashmem, in that case.
Differential Revision: https://phabricator.services.mozilla.com/D90605
This commit also allows `memfd_create` in the seccomp-bpf policy for all
process types.
`memfd_create` is an API added in Linux 3.17 (and adopted by FreeBSD
for the upcoming version 13) for creating anonymous shared memory
not connected to any filesystem. Supporting it means that sandboxed
child processes on Linux can create shared memory directly instead of
messaging a broker, which is unavoidably slower, and it should avoid
the problems we'd been seeing with overly small `/dev/shm` in container
environments (which were causing serious problems for using Firefox for
automated testing of frontend projects).
`memfd_create` also introduces the related operation of file seals:
irrevocably preventing types of modifications to a file. Unfortunately,
the most useful one, `F_SEAL_WRITE`, can't be relied on; see the large
comment in `SharedMemory:ReadOnlyCopy` for details. So we still use
the applicable seals as defense in depth, but read-only copies are
implemented on Linux by using procfs (and see the comments on the
`ReadOnlyCopy` function in `shared_memory_posix.cc` for the subtleties
there).
There's also a FreeBSD implementation, using `cap_rights_limit` for
read-only copies, if the build host is new enough to have the
`memfd_create` function.
The support code for Android, which doesn't support shm_open and can't
use the memfd backend because of issues with its SELinux policy (see bug
1670277), has been reorganized to reflect that we'll always use its own
API, ashmem, in that case.
Differential Revision: https://phabricator.services.mozilla.com/D90605
This patch extends shared memory freezing to support the use case where
the parent process retains write access for incremental updates, while
other processes receive read-only access.
Note that, while some OSes allow independent read-only and read/write
capabilities for the same object, all we have on Android is an operation
that prevents future write mappings. Therefore, this allows an existing
writeable mapping to be retained, but if that is unmapped then even the
parent process can't re-create it.
As with freezing, the read-only restriction may not be enforceable if
the recipient process isn't adequately sandboxed (e.g., on Linux, if it
can use /proc/self/fd to reopen the inode for writing).
Differential Revision: https://phabricator.services.mozilla.com/D67187
Sylvestre Ledru