Graceful Handling of OOM in table.grow
#5394
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
syrusakbary
reviewed
Feb 17, 2025
charmitro
force-pushed
the
table-grow-max
branch
2 times, most recently
from
080a2be to
532b0a9
Compare
This commit enhances the `VMTable::grow` method to impose a uniform failure condition for extreme table growth requests, addressing platform-specific discrepancies observed in prior implementations (e.g., Linux returning -1 due to strict allocation limits, macOS returning 0 due to virtual memory overcommitment). Introduce `DEFAULT_MAX_TABLE_SIZE` set to 1,048,576 elements (~1 million, 2^20) as a default cap for tables lacking a specified maximum (`self.maximum = None`). This prevents impractical growth attempts, such as a delta of 0xff_ff_ff_ff (4,294,967,295 elements), which could succeed misleadingly on overcommitting systems like macOS. Replace panic-prone `Vec::resize` with `try_reserve_exact` to attempt memory reservation before resizing. Returns `None` (mapping to WebAssembly’s -1) on allocation failure, ensuring graceful handling of out-of-memory (OOM) conditions rather than crashing, as seen previously on Linux with large deltas. Update growth logic to compute the effective maximum (`self.maximum.unwrap_or(DEFAULT_MAX_TABLE_SIZE)`), failing early if `new_len` exceeds this limit, followed by a safe reservation and resize sequence. These changes align with the WebAssembly 2.0 (Draft 2025-01-28) spec’s allowance for implementation-defined resource limits (Section 7.2) and `table.grow` semantics (returning -1 on exceeding limits or resource constraints). Signed-off-by: Charalampos Mitrodimas <[email protected]>
Adds a new test to verify table.grow behavior with very large delta (0xff_ff_ff_ff). Signed-off-by: Charalampos Mitrodimas <[email protected]>
charmitro
force-pushed
the
table-grow-max
branch
from
532b0a9 to
53eb883
Compare
syrusakbary
approved these changes
Feb 27, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduce
DEFAULT_MAX_TABLE_SIZEset to 1,048,576 elements (~1million, 2^20) as a default cap for tables lacking a specified
maximum (
self.maximum = None). This prevents impractical growthattempts, such as a delta of 0xff_ff_ff_ff (4,294,967,295 elements),
which could succeed misleadingly on overcommitting systems like macOS.
Replace panic-prone
Vec::resizewithtry_reserve_exactto attemptmemory reservation before resizing. Returns
None(mapping toWebAssembly’s -1) on allocation failure, ensuring graceful handling of
out-of-memory (OOM) conditions rather than crashing, as seen
previously on Linux with large deltas.
Update growth logic to compute the effective
maximum (
self.maximum.unwrap_or(DEFAULT_MAX_TABLE_SIZE)), failingearly if
new_lenexceeds this limit, followed by a safe reservationand resize sequence.
These changes align with the WebAssembly 2.0 (Draft 2025-01-28) spec’s
allowance for implementation-defined resource limits (Section 7.2) and
table.growsemantics (returning -1 on exceeding limits or resourceconstraints).