Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 06c57fbad9f61be9b44101f57764e9257bf700c8
https://github.com/WebKit/WebKit/commit/06c57fbad9f61be9b44101f57764e9257bf700c8
Author: Marcus Plutowski <[email protected]>
Date: 2026-05-07 (Thu, 07 May 2026)
Changed paths:
A JSTests/stress/many-locals-in-generator-suspension.js
M Source/WTF/wtf/DoublyLinkedList.h
M Source/WTF/wtf/SequesteredAllocator.h
M Source/WTF/wtf/SequesteredImmortalHeap.cpp
M Source/WTF/wtf/SequesteredImmortalHeap.h
Log Message:
-----------
[SequesteredMalloc] Support arbitrary-size allocations
https://bugs.webkit.org/show_bug.cgi?id=313697
rdar://175894622
Reviewed by Yusuke Suzuki.
Previously, the SequesteredArenaAllocator did not support allocations
larger than the 512k granule size.
In order to do so, this patch adds a structure similar to libpas'
large-heap/large-map, with a few key distinctions.
1. Rather than lazily coalescing free-ranges, we do so eagerly on
decommit. This means that we don't have a ready pool of committed
memory to pull from on alloc, but saves significant complexity,
and due to the rarity of large allocations in this allocator is
unlikely to be a performance problem.
In particular, this means we don't have a physical sharing pool
or any analogous structure.
2. Correspondingly, instead of a cartesian tree, we store freed
granules in a sorted list, as we don't need to do range-checks.
Coalescing happens on insertion.
3. Unlike libpas, we currently don't support a mechanism for
decomitting the handles used for tracking granules when not
currently in use. This only happens after range-coalescing,
and even if we presume that all but 1 large allocations are
allocated with the minimum size and then coalesced, we would
waste at most 1/8000th of physical memory --
512k minimum size for a large allocation, 64B per granule header.
4. The hashmap used for tracking large allocations does not support
any form of compression. Given the small number of anticipated
large allocations, this is certainly fine.
Otherwise, the mechanism is rather similar.
Allocations above a certain size are allocated "directly" from mmap,
unless a free range of sufficient size is already available. Each range
so allocated is tracked using a GranuleHeader. To distinguish headers
tracking a single Large object from those tracking potentially many
sub-page ones, this patch adds an enum tag to GranuleHeader which
defines its role.
Maintaining a single 'granule' concept allows us to take advantage of
the existing deferred-decommit queue by just tacking these
large-allocations onto it like they were a normal slab of memory.
After allocation, live allocations are tracked in a hashmap. When freed,
they are put on the deferred decommit queue, and when the scavenger gets
around to them they are put onto an ordered free list in the large-map
and coalesced as appropriate.
Canonical link: https://commits.webkit.org/312809@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
