[wasm] Fix fragmentation caused by large objects allocation #118099
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR addresses memory fragmentation issues in WebAssembly (WASM) builds by disabling the Large Object Space (LOS) sections allocator. Instead of using 1MB-aligned LOS sections for objects between 8K and 1MB, it allocates each large object independently from the OS, eliminating fragmentation while improving allocation speed by ~20%.
Key changes:
- Introduces a compile-time flag to disable LOS sections allocator on WASM
- Updates allocation and deallocation logic to handle direct OS memory allocation when sections are disabled
- Adds early return in consistency checking when sections allocator is disabled
|
Tagging subscribers to this area: @BrzVlad |
Allocation in the segments is normally done for objects smaller than 1MB. The problem is that for los sections we require 1MB alignment and on wasm we end up allocating twice the memory in order to ensure the alignment. With this commit we reuse the same allocation code that was used for objects bigger than 1MB. This still uses the unfortunate alignment of page size.
…TION_OBJECT_LIMIT On mono, objects need to have the alignment of 8 bytes. We allocate using this alignemnt directly for objects smaller than 1MB. This further decreases fragmentation and increases allocation speed.
BrzVlad
force-pushed
the
fix-wasm-los-fragmentation
branch
from
d118803 to
73b757a
Compare
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This comment was marked as resolved.
This comment was marked as resolved.
This will produce some waste, but 512 alignment is still quite small compared to the size of the objects here (> 8k)
BrzVlad
force-pushed
the
fix-wasm-los-fragmentation
branch
from
15a68b0 to
d995297
Compare
|
@pavelsavara this seems green now |
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
I guess that objects on LOS are never moved, so from this perspective it's no change and no perf impact.
I wonder if there is a allocation pattern for which this will cause more fragmentation than the previous state.
cc @kg
|
/ba-g all the CI failures are unrelated |
|
In my microbenchmark, allocation was actually faster with this change. However, allocation speed and fragmentation will depend on the |
For large objects (bigger than 8K), we have two different allocators. We either allocate them in LOS sections (a section has 1MB), if the object is smaller than 1MB in size, or allocate it directly from the OS. A LOS section has 1MB alignment. On wasm this huge alignment is problematic leading to memory fragmentation. This PR disables allocation from LOS sections, allocating each object independently.
Testing allocation for 10k sized objects with
console-v8this change showed the following resultsGC.GetGCMemoryInfo:Fixes #118044