HostSharedMemory::zero_or_replace() currently uses a compile-time #[cfg(target_os = "windows")] check to decide whether to zero scratch in-place or replace it with a fresh demand-zero allocation. This works for the immediate problem (large scratch regions on WHP), but the real decision depends on the hypervisor and the size of the region, not just the platform.
There is a break-even point between zero-in-place (via MADV_DONTNEED or fill(0)) and delete+recreate (fresh ExclusiveSharedMemory::new) that varies by:
- Hypervisor (KVM, MSHV, WHP)
- Scratch region size
- Whether
MADV_DONTNEED is available (KVM-only builds vs KVM+mshv3)
We should benchmark across these configurations and replace the compile-time platform check with a size-based heuristic. This would also allow MSHV builds on Linux to benefit from the fresh-allocation path for large scratch regions.
Ref: #1765
HostSharedMemory::zero_or_replace()currently uses a compile-time#[cfg(target_os = "windows")]check to decide whether to zero scratch in-place or replace it with a fresh demand-zero allocation. This works for the immediate problem (large scratch regions on WHP), but the real decision depends on the hypervisor and the size of the region, not just the platform.There is a break-even point between zero-in-place (via
MADV_DONTNEEDorfill(0)) and delete+recreate (freshExclusiveSharedMemory::new) that varies by:MADV_DONTNEEDis available (KVM-only builds vs KVM+mshv3)We should benchmark across these configurations and replace the compile-time platform check with a size-based heuristic. This would also allow MSHV builds on Linux to benefit from the fresh-allocation path for large scratch regions.
Ref: #1765