<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 28 April 2018 at 16:57, Clément Bera <span dir="ltr"><<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr">Hi Eliot, Hi all,<div><div><br></div><div>On mac and linux, Spur uses <font face="monospace, monospace">mmap</font> to allocate new segments. The V3 memory manager used <font face="monospace, monospace">malloc</font> instead. I've looked into many other VMs (Javascript and Java), and most of them use <font face="monospace, monospace">posix_memalign </font><font face="arial, helvetica, sans-serif">(basically malloc where you can ask for specific alignment)</font><font face="monospace, monospace">. </font></div><div><br></div><div>I am wondering why we are using <font face="monospace, monospace">mmap</font> over <span style="color:rgb(34,34,34);font-family:monospace,monospace;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">posix_memalign / malloc</span><span style="color:rgb(34,34,34);font-family:monospace,monospace;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="color:rgb(34,34,34);font-family:monospace,monospace;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">. </span></span><span style="font-family:arial,helvetica,sans-serif">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?</span></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div>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 <span style="color:rgb(34,34,34);font-family:monospace,monospace;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">posix_memalign / malloc </span><span style="color:rgb(34,34,34);font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><font face="arial, helvetica, sans-serif">to allocate new memory segment if I do that ? Or d</font></span>oes 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 ? </div><div><br></div><div>Thanks,</div><div><br></div>-- <br><div class="gmail-m_-1991351035374115980gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><span style="font-size:12.8px">Clément Béra<br></span><span style="color:rgb(0,0,238)"><a href="https://clementbera.github.io/" target="_blank">https://clementbera.github.io/</a></span><div style="font-size:12.8px"><a href="https://clementbera.wordpress.com/" target="_blank">https://clementbera.wordpress.<wbr>com/</a></div></div></div></div></div></div>
</div></div>
<br></blockquote><div><br></div><div>btw, the 

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">mmap<span> </span></span>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?</div><div><br></div><div>

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><a href="https://github.com/rumpkernel/wiki/wiki/Info:-FAQ">https://github.com/rumpkernel/wiki/wiki/Info:-FAQ</a></span>

<br></div><div>"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."<br></div></div><br></div><div class="gmail_extra">cheers -ben</div></div>