You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix GC heap using wrong MemoryKind tunables in on-demand allocator (#13189)
* Fix GC heap using wrong `MemoryKind` tunables in on-demand allocator
The on-demand instance allocator's `allocate_memory` always passed
`MemoryKind::LinearMemory` to `Memory::new_dynamic`, even when
allocating the backing memory for a GC heap. This caused the GC heap to
use the wrong set of tunables.
The consequences were two distinct crash modes:
1. When `memory_reservation=0`: the GC heap got a 0-byte reservation, so every
growth triggered an mmap reallocation that changed the base pointer. Code
held a stale cached copy of the old base pointer, causing use-after-free
crashes.
2. When `gc_heap_guard_size != memory_guard_size`: Cranelift correctly compiled
GC heap accesses using `gc_heap_guard_size` bytes of virtual guard, but the
runtime memory incorrectly only had `memory_guard_size` bytes of actual
guard, so accesses beyond the actual guard caused uncaught segfaults.
This commit fixes the bug by threading a `MemoryKind` through the
`InstanceAllocator::allocate_memory` trait method.
Also, now that the GC heap correctly uses `gc_heap_reservation`, the workaround
in `MemoryTunables::may_move` that always returned `true` for GC heaps is no
longer needed. That workaround was masking the actual root cause, and with the
fix, `gc_heap_may_move` can now be respected correctly.
There were three existing tests that were accidentally relying on the GC heap
using linear-memory tunables; this commit adds explicit GC heap tunable
configuration so they continue to work correctly.
Fixes#13173
* Fix compiler warning
0 commit comments