Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 06d5550e6d760d556d785bbdb21f3c2a49b8f68b
https://github.com/WebKit/WebKit/commit/06d5550e6d760d556d785bbdb21f3c2a49b8f68b
Author: Mark Lam <[email protected]>
Date: 2025-12-12 (Fri, 12 Dec 2025)
Changed paths:
M Source/JavaScriptCore/assembler/MacroAssemblerARM64E.h
M Source/WTF/wtf/CagedPtr.h
M Source/WTF/wtf/Gigacage.h
M Source/WTF/wtf/PlatformHave.h
M Source/bmalloc/bmalloc/BPlatform.h
M Source/bmalloc/bmalloc/Gigacage.h
M Source/bmalloc/libpas/src/libpas/pas_platform.h
Log Message:
-----------
Disable use of HAVE(36BIT_ADDRESS).
https://bugs.webkit.org/show_bug.cgi?id=304052
rdar://166369379
Reviewed by Keith Miller.
We cannot guarantee that the kernel will always map pages with 36-bit
addresses. As such, we
cannot use HAVE(36BIT_ADDRESS). For now, we will simply disable the use of
HAVE(36BIT_ADDRESS)
instead of removing the code completely. We will completely remove the
HAVE(36BIT_ADDRESS)
code after we have some baking time.
Also clean up or fix some uses of EFFECTIVE_ADDRESS_WIDTH that fall out of
disabling
HAVE(36BIT_ADDRESS). This includes:
1. Removed tagArrayPtr, untagArrayPtr, untagArrayPtrLength64, and
removeArrayPtrTag functions
from MacroAssemblerARM64E.h. These functions are now unused.
With that, we can remove the maxNumberOfAllowedPACBits constant which relies
on
OS_CONSTANT(EFFECTIVE_ADDRESS_WIDTH), which ultimately relies on
HAVE(36BIT_ADDRESS).
This constant was previously being used by removeArrayPtrTag. The number of
PAC bits is
not ABI. Hence, it is generally not ABI safe / stable to rely on this.
Hence, I opted
to just remove this code since they are unused anyway.
2. Removed some unused constants in CagePtr.h that rely on
OS_CONSTANT(EFFECTIVE_ADDRESS_WIDTH).
3. Fix hasCapacityToUseLargeGigacage to not rely on
OS_CONSTANT(EFFECTIVE_ADDRESS_WIDTH).
OS_CONSTANT(EFFECTIVE_ADDRESS_WIDTH) may not be a good signal on whether we
can afford
to use a large Gigacage or not. Instead, just set this value based on
whether we're
targetting an embedded platform, or not.
Also set hasCapacityToUseLargeGigacage to false for CPU(ADDRESS32) just for
consistency.
Note: CPU(ADDRESS32) platforms do not actually enable Gigacage.
No new tests. This is just a feature disablement. The affected code will
already be
covered by existing tests.
* Source/JavaScriptCore/assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::tagArrayPtr): Deleted.
(JSC::MacroAssemblerARM64E::untagArrayPtr): Deleted.
(JSC::MacroAssemblerARM64E::untagArrayPtrLength64): Deleted.
(JSC::MacroAssemblerARM64E::removeArrayPtrTag): Deleted.
* Source/WTF/wtf/CagedPtr.h:
* Source/WTF/wtf/Gigacage.h:
* Source/WTF/wtf/PlatformHave.h:
* Source/bmalloc/bmalloc/BPlatform.h:
* Source/bmalloc/bmalloc/Gigacage.h:
* Source/bmalloc/libpas/src/libpas/pas_platform.h:
Canonical link: https://commits.webkit.org/304363@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
