Stream: git-wasmtime

Topic: wasmtime / issue #4986 Always use mmap instead of posix_m...

Wasmtime GitHub notifications bot (Sep 30 2022 at 16:18):

bjorn3 opened issue #4986:

This currently behind the selinux-fix feature flag. SELinux doesn't allow making parts of the heap executable. In addition it seems that there is an issue in multithreaded environments causing permission issues leading to crashes when using posix_memalign instead of mmap. (see https://github.com/bytecodealliance/wasmtime/issues/4980) I don't know why using posix_memalign was chosen initially. Maybe there is some advantage to it that I don't know of. If not, I don't see any reason to stay with posix_memalign as default. @sunfishcode do you remember why you used posix_memalign?

Wasmtime GitHub notifications bot (Sep 30 2022 at 17:10):

sunfishcode commented on issue #4986:

It's std::alloc::alloc now, rather than posix_memalign, but the same question applies.

I think the reason was that alloc/posix_memalign can be faster, because it can reuse free memory that the allocator has, rather than always requiring an mmap system call to allocate and a munmap system call to free each time. However, I don't have any data on whether it's actually faster.

Wasmtime GitHub notifications bot (Sep 30 2022 at 17:21):

bjorn3 commented on issue #4986:

Maybe we could make a simple memory allocator ourself? Unlike system allocators it doesn't have to deal with tiny allocations or allocations of fixed sizes, so complexity from that doesn't have to exist and it could be made aware of which page has which memory protection applied so that once a page is made executable it will only consider it allocatable once every function stored in it has been deallocated. This way it is also no longer necessary to allocate multiples of the page size.

Wasmtime GitHub notifications bot (Sep 30 2022 at 17:27):

bjorn3 commented on issue #4986:

Another advantage of that would be that it allows keeping all code within 2GB even when allocating a lot of memory in between compiling functions. This is necessary to avoid the panics at https://github.com/bytecodealliance/wasmtime/blob/c1d6ca48a74ab6f356d08baa533b90b17ccb834a/cranelift/jit/src/compiled_blob.rs#L60 and elsewhere during applying of relocations.

Wasmtime GitHub notifications bot (Oct 05 2022 at 08:35):

Mrmaxmeier commented on issue #4986:

I'm using a simple mmap-based allocator to work around #4000 (^) here: https://github.com/Mrmaxmeier/wasmtime/commits/cranelift-jit-reserve-vmem-area
The branch is mostly a hack though and made for easy rebasing, but feel free to benchmark the mmap overhead with it ^^

Last updated: Oct 23 2024 at 20:03 UTC