mps
mps copied to clipboard
Ravenbrook
MPS as an OS-wide memory manager?
Assume we integrated MPS into the kernel of a Unix-like operating system, so that each userland program could use this built-in API for memory management instead of the traditional ones like sbrk() and mmap(). Things like malloc() and mmap() could be emulated on top of MPS primitives so that legacy programs keep working.
Would MPS gain any advantages (performance- or simplicity-wise) over the current approach where each userland program that wants to use MPS has its own copy running entirely in userland?
If MPS was integrated into the OS kernel, would there be an advantage to running parts of it in kernel space, e.g. garbage collection, or would those routines be best kept running in userspace?
Thanks for asking this question. This is more of a discussion point than an issue with the MPS. We may well open up the GitHub discussions system for things like this.
Assuming for the moment you are just talking about manual memory management (not garbage collection) there would likely be little advantage. Leaving the MPS aside for the moment, let's suppose we merged virtual memory management (supplying raw virtual pages with mmap and sbrk) with memory block allocation (malloc) and provided malloc from the kernel. This would mean a lot of system calls and context switching to provide small blocks of memory, which would be a large performance hit. Malloc in userland can do millions of operations without a system call to manage virtual memory. This makes sense in the memory hierarchy. If the MPS were in the kernel it would have the same problem.
In terms of code sharing, if the MPS were a shared library on the OS, e.g. at /usr/lib/mps.so, then each process will be mmapping the code into its own address space, and the kernel should be sharing the physical RAM between the running processes on the machine, as it does with any shared library. The processor can then cache that code across processes and threads. There would be no advantage in code sharing terms to moving the MPS into the kernel.
About garbage collection, there is potentially a big advantage. At present, the MPS can't scan memory while the mutator is runnng: it requires exclusive access to memory. If the MPS could use a separate memory protection map then it would be possible for it to scan while allowing mutator threads to continue. One way to achieve this would be to have the MPS "in the kernel", but a better way would be to improve the kernel so that threads could, in general, have their own protection maps. This may now be possible using, e.g. pkeys and this is something I'd like to look in to in detail.
One way to achieve this would be to have the MPS "in the kernel", but a better way would be to improve the kernel so that threads could, in general, have their own protection maps.
On Linux, could userfaultfd be a mechanism that enables this? It can be used as an alternative to mprotect/SIGSEGV on recent kernels. See e.g.
https://medium.com/@MartinCracauer/generational-garbage-collection-write-barriers-write-protection-and-userfaultfd-2-8b0e796b8f7f https://www.cons.org/cracauer/cracauer-userfaultfd.html
