<div dir="ltr">Hi Clémewnt,<div><br></div><div>   sorry for the late reply...</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 28, 2018 at 1:57 AM, 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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><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></div></blockquote><div><br></div><div>And on Windows it uses VirtualAlloc.  So it is consistent in using memory mapping to allocate segments across the platforms, where available.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I am wondering why we are using <font face="monospace, monospace">mmap</font> over <span style="font-family:monospace,monospace;font-variant-ligatures:normal">posix_memalign / malloc</span><span style="font-family:monospace,monospace;font-variant-ligatures:normal"><span style="font-variant-ligatures:normal">. </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><br></div></div></blockquote><div><br></div><div>Well, I don't like using malloc because one is layering unnecessarily and hence there is wastage.  Many malloc implementations are optimized for small block sizes and allocating a huge block</div><div>- may have a segment allocated all to itself</div><div>- won't necessarily be on a page boundary (especially on systems with very large pages)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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="font-family:monospace,monospace;font-variant-ligatures:normal">posix_memalign / malloc </span><span style="font-variant-ligatures:normal"><font face="arial, helvetica, sans-serif">to allocate new memory segment if I do that ?</font></span></div></div></blockquote><div><br></div><div>Sure, but why?  Given that using mmap/VirtualAlloc gives page alignment, one is going to get alignment up to at least 256 bytes (ancient VAX page size) and more typically 4k bytes (x86/x86_64) .</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-variant-ligatures:normal"><font face="arial, helvetica, sans-serif"> 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 ? <br></div></div></blockquote><div><br></div><div>Well indeed being able to reply on ordering makes the boundary checks in the store checks simpler.  I think you wrote a blog post on this so you;ve actually captured this info before.  But to reiterate, the Cog and Stack VM assumes the following memory orderings:</div><div><br></div><div>1. all primitive functions are above 1024.  This allows the quick primitives to be stored in the method cache with a primitive function pointer that is their index and for executeNewMethod et al to compare the primitiveFunctionPointer against MaxQuickPrimitiveIndex and dispatch to quickPrimitiveResponse</div><div><br></div><div>2. New space is below all old space segments, and is immediately below the first old space segment.  This allows isOldObject:/isYoungObject: et al to compare an oop against newSpaceLimit/oldSpaceStart/nilObj (yes we have three different names for exactly the same value; we only need two; the fact that nilObj = oldSpaceStart is incidental).</div><div><br></div><div>3. the code zone is below new space.  This allows isReallyYoungObject: to use two comparisons, instead of three.</div><div><br></div><div>So let me ask you the corollary.  Why, if mmap/VirtualAlloc provides memory aligned on a page boundary, with no overhead, and control over placement, why would one use posix_memalign or malloc to allocate memory?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>Thanks,</div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="gmail-m_3718303252889089252gmail_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>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>