[Vm-dev] Spur Memory segment and OS allocation

[Ben Coman]

On 28 April 2018 at 16:57, Clément Bera <bera.clement at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180428/368ca273/attachment.html>