On 28 April 2018 at 16:57, Clément Bera bera.clement@gmail.com wrote:
Hi Eliot, Hi all,
On mac and linux, Spur uses mmap to allocate new segments. The V3 memory manager used malloc instead. I've looked into many other VMs (Javascript and Java), and most of them use posix_memalign (basically malloc where you can ask for specific alignment).
I am wondering why we are using mmap over posix_memalign / malloc. The only reason I can find is that Spur always allocate new memory segments at a higher address than past segments to guarantee that young objects are on lower addresses than old objects for the write barrier. Is that correct?
Assuming it is correct, let's say I change Spur to implement the write barrier differently (typically, I change all objects to be aligned on 128 bits instead of 64 and have different allocation alignment for young (128 bits alignment) and old objects(128+64 bits alignment)). Will we be able to use posix_memalign / malloc to allocate new memory segment if I do that ? Or does the VM rely on segments being on higher addresses for other reasons ? For example, does the VM assume CogMethods are on lower addresses than objects on heap and rely on it to check if a stack frame is mframe or iframe ?
Thanks,
-- Clément Béra https://clementbera.github.io/ https://clementbera.wordpress.com/
btw, the mmap requirement was a blocker when I looked into trying the VM on the Rumprun unikernel for Xen. Although MAP_ANON seems new - would that be sufficient?
https://github.com/rumpkernel/wiki/wiki/Info:-FAQ "For simplicity reasons, the Rumprun unikernel does not support virtual memory -- unnecessary in a unikernel -- nor does it support signals the traditional way. That means that programs which absolutely depend on things like fork(), execve(), mmap() and sigaction() may not work correctly. In some cases we provide a small amount of cheap emulation for common cases (e.g. mmap(MAP_ANON)). Yes, we could add virtual memory support, but we choose not to, because we would rather concentrate on running 90% of existing applications really well instead of running 99% of existing applications in a mediocre fashion."
cheers -ben