<div dir="ltr"><div class="gmail_extra">On Wed, Sep 25, 2013 at 10:39 AM, tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
On 25-09-2013, at 9:30 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
<br>
> Off the top of my head it may need the memory manager to add a "sliver" object type, an 8-byte header with no fields, that is collected by coallescing with adjacent free blocks, that can fill in the 8-byte gaps aligning pinned objects on 16 byte boundaries would create. I'll think about this.<br>
><br>
<br>
</div>Wild-ass suggestion; would it work to allocate the relevant object (which I'm assuming here is essentially an UninterpretedBytes) with an 'extra' 8 bytes and then store the 'real' bits at the right place to have the 16byte boundary? Yes, there would have to be magic to signify where the real start of data is. Yes, it would potentially change on scavenge, but since these are largely pinned, not such a big issue maybe?<br>
</blockquote><div><br></div><div>In general that's a bad idea because it loads the frequent path (accessing the object) with the work, unloading the infrequent path (pinning the object). It can't happen during scavenge because by definition pinned objects are not in new space. hence I think the time to take the hit is on pinning (an infrequent operation). Make sense?</div>
<div><br></div></div>-- <br>best,<div>Eliot</div>
</div></div>