> On Feb 3, 2025, at 5:30 PM, Samuel Hym <sam...@tarides.com> wrote: > >> My understanding of the issue was to munmap of a chunk inside an mmapped >> region, which requires a full mmap/munmap implementation (we don't have >> currently). I'm not sure where the code that causes the ABORT lives and >> maybe it can be difficult to trigger the situation? > > `abort` would be triggered by a `free(x)` where `x` is not the result > of a `malloc`. > As I didn’t manage to create an example using the compactor that would > run into such a situation and I couldn’t find at which point in the > code that could be triggered, I reached out to Sadiq. He confirmed > that our implementation is correct. > What happens is that, as pools are allocated by the GC, they will > probably follow each other in the virtual memory address space; the > compactor might decide to release a pool in the middle of that > sequence of pools, so we’ll end up with (coarse-grained) fragmentation > with our `malloc`/`free` implementation. But it will be valid > nevertheless!
My suggestion to Sadiq when we were discussing the compactor a few months ago was to not reinvent the wheel but to use https://github.com/microsoft/mimalloc instead. It's a state of the art malloc implementation with a very easy integration path to be directly embedded into a Mirage runtime. I think it would probably work out better than using a generic libc malloc in Unikraft (and certainly better than newlib's malloc implementation). I put together a quick tree last year that just directly vendored mimalloc, and the integration was pretty straightforward. As always, 80% of the effort will be in the build system integration, which I didn't do ;-) best, Anil
