Always use mmap instead of posix_memalign in cranelift-jit

[bjorn3]

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 #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?

[sunfishcode]

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.

[bjorn3]

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.

[bjorn3]

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

wasmtime/cranelift/jit/src/compiled_blob.rs

Line 60 in c1d6ca4

let pcrel = i32::try_from((what as isize) - (at as isize)).unwrap();

and elsewhere during applying of relocations.

[Mrmaxmeier]

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 ^^