<div dir="ltr">On Wed, Dec 16, 2015 at 10:34 PM, Ryan Macnak <span dir="ltr"><<a href="mailto:rmacnak@gmail.com" target="_blank">rmacnak@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 16, 2015 at 3:20 PM, Ben Coman <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
On Thu, Dec 17, 2015 at 4:13 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
> There are constraints here. The VM assumes the following memory order:<br>
><br>
> Low addresses:<br>
> machine code zone<br>
> new space<br>
> first heap segment<br>
><br>
> High addresses<br>
> subsequent heap segments</blockquote><div><br></div><div>I know new space < old space is relied on for store buffer checks. Is the relative order of the code zone and the heap ever used?</div></div></div></div></blockquote><div><br></div><div>Rather than used, it is coped with. See SpurMemoryManager>>isYoungObject: & isReallyYoungObject: & Spur[32|64]BitCoMemoryManager>>isReallyYoungObject:. The code zone can go anywhere, but if it goes below new space (as it does currently) then the scavenger needs to use isReallyYoungObject: so as not to be confused by the CogMethod references in cogged CompiledMethods.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Thinking long term, this reliance on ordering is bad for address space randomization or having multiple heaps in the same process (e.g., having concurrent actors with fast messaging). The Dart VM uses object alignment to distinguish object age, though it doesn't have immediate characters or floats contending for that bit.</div></div></div></div></blockquote><div><br></div><div>Agreed. But it is nice to be able to use a single bounds check. I'm happy to maintain two versions when address randomisation and/ior unikernels force two checks.</div><div><br></div><div>The alignment issue is trickier than that. Right now Spur has an 8 byte alignment, so bit 1 << 3 can vary. Aligning object headers on a 16 byte boundary, thereby allowing bit 1 << 3 to be used to mark age, would involve padding half of the objects with another 8 byte word, and that's of the order of a 7% hit on memory usage in 64-bits and 6% in 32-bits (*). So while the alignment trick is fast to test I don't think it pays for itself.</div><div><br></div><div>(*) surprised me, but that's what I measured. Since Spur rounds object up to 8 bytes, a 1 inst var 32-bit obj takes the same size as a 2 inst var 32-bit obj. So I guess that this rounding has the effect of ending up with more 32-bit objects aligned on a 16-byte boundary than 64-bit ones. That seems to be the case; in my reader image 141871 32-bit objects need rounding up whereas 232742 64-bit ones do. In my reader image there are 384388 64-bit objects and 413845 32-bit ones. I guess that means 29457 fewer objects due to the larger immediate range and immediate floating point. Not too shabby :-) [but it's late; take these numbers with a grain of salt]</div><div><br></div></div><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>