<div dir="ltr">Hi Tim, Hi All,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 25, 2013 at 12:46 PM, tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 25-09-2013, at 11:36 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
<br>
> On Wed, Sep 25, 2013 at 10:39 AM, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br>
><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>
> 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>
><br>
> 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?<br>
<br>
</div></div>Almost always. But it's worth throwing wild ideas around occasionally just to see if they stick to the blanket.<br></blockquote><div><br></div><div>Yes!! I was almost going to post something on just this point. Thanks for the prompt. I want to encourage everyone to throw ideas out there without fear of their being proved wrong. Discussing the ideas has great value whether or not they;re right. The other day Clement had a good idea about become. I'd not thought about the issue he brought up before, and his suggestion, even though I don't think it'll work, made me think about the issue and helped clarify my thinking. So yes, please keep throwing out those ideas. And don't get discouraged by critical responses.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How about two subclasses - one for each possible 8byte alignment? The FFI code only gets a ptr to the right place anyway, so it won't care. Accessor methods would be minimally different for the two subclasses and handle the offset for ST code. Compacting, if it ever touched instances, would swap the class if required. How's that for adaptive optimisation ;-)<br>
</blockquote><div><br></div><div>That could work, but offends my sense of the separation between the system and the VM. So I don't feel like going there :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Or how about simply not allocating the actual memory in object space? I know it can be a pain but perhaps it's less of a pain in the end.<br></blockquote><div><br></div><div>That one can always do. The FFI will always provide some sort of interface to malloc and/or valloc (even if it is as primitive as actually calling those functions). But the question for Spur is what facilities it should provide and I want to provide something much easier to use (i.e. pinned ByteArrays and the like). </div>
<div><br></div></div>-- <br>cheers,<div>Eliot</div>
</div></div>