Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 0de9a179e544a6932f063d2b00c6781de4b5700a
https://github.com/WebKit/WebKit/commit/0de9a179e544a6932f063d2b00c6781de4b5700a
Author: Marcus Plutowski <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M Source/bmalloc/libpas/src/libpas/pas_bitfit_page_inlines.h
M Source/bmalloc/libpas/src/libpas/pas_fast_megapage_table.h
M Source/bmalloc/libpas/src/libpas/pas_local_allocator_inlines.h
M Source/bmalloc/libpas/src/libpas/pas_mte.h
M Source/bmalloc/libpas/src/libpas/pas_mte_config.h
M Source/bmalloc/libpas/src/libpas/pas_page_granule_use_count.h
M Source/bmalloc/libpas/src/libpas/pas_zero_memory.h
Log Message:
-----------
[libpas] Implement Retag-on-Scavenge for segregated objects
https://bugs.webkit.org/show_bug.cgi?id=302663
rdar://164906028
Reviewed by Dan Hecht.
The original implementation of retag-on-scavenge was insufficient,
but at the time its problems were masked by other bugs (mainly
the performance bug wherein we allocated all pages with backing
MTE memory, even when they were intended only for allocating
compact objects). Secondly, they were also masked by recently-
modified page configurations which ensured that certain allocation
paths were not reached in practice in those places where the feature
was enabled. This patch goes over and fixes those issues for segregated
objects in particular, thus enabling the feature in privileged
processes.
The main issues:
- The way we were previously checking whether or not an allocation
should be re- tagged relied on the page configuration. However, that
does not always work because the local-allocator can also decide to
use a tagged page-config to ultimately allocate *untagged* memory.
Since the metadata used to make this decision is not accessible on
the deallocation path, we instead determine it 'experimentally' by
executing an LDG instruction on the page. Since libpas makes sure to
never explicitly zero-tag an allocation inside of an MTE-backed page,
if we get a zero-tag back that means the object is canonically tagged
-- i.e., has no backing MTE tag memory.
- Bitfit heaps, unlike segregated heaps, can allocate objects of
different sizes in the same memory location. This complicates both
the process of determining the size of an object being freed as well
as making it impossible to elide re-tagging an object on allocation,
as the deallocation path cannot know the size of the next object to
be allocated in a given slot. This patch thus disables the bitfit
retag-on-scavenge path for the time being, pending future work.
As part of the above work, this patch also refactors some components to
use always-inline functions instead of macros, as part of a general
intent to move away from the heavily macro-ified and indirect approach
that was an artifact of how libpas MTE was developed on a side-tree prior
to the announcement of MIE.
* Source/bmalloc/libpas/src/libpas/pas_bitfit_page_inlines.h:
(pas_bitfit_page_finish_allocation):
* Source/bmalloc/libpas/src/libpas/pas_fast_megapage_table.h:
* Source/bmalloc/libpas/src/libpas/pas_local_allocator_inlines.h:
(pas_local_allocator_try_allocate_in_primordial_partial_view):
(pas_local_allocator_try_allocate_with_free_bits):
* Source/bmalloc/libpas/src/libpas/pas_mte.h:
(pas_mte_maybe_tag_allocated_region):
(pas_mte_retag_freed_region_if_tagged):
* Source/bmalloc/libpas/src/libpas/pas_mte_config.h:
* Source/bmalloc/libpas/src/libpas/pas_page_granule_use_count.h:
* Source/bmalloc/libpas/src/libpas/pas_zero_memory.h:
(pas_zero_memory):
Canonical link: https://commits.webkit.org/303396@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
