[Vm-dev] [Pharo-dev] [NB] Trying to implement a ReadStream on NBExternalAddress

Eliot Miranda eliot.miranda at gmail.com
Wed Sep 25 16:30:47 UTC 2013


On Wed, Sep 25, 2013 at 1:14 AM, Henrik Johansen <
henrik.s.johansen at veloxit.no> wrote:

>
> On Sep 24, 2013, at 9:58 , Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> On Mon, Sep 23, 2013 at 3:10 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>> Isn't Eliot just implementing this feature, having a segment of non
>> relocatable objects?
>>
>
> Sort of.  Spur will allow any object in old space to stay still, and
> through become can move any object to old space very simply.  So instead of
> having a special fixed space segment it has a best-bit compaction algorithm
> that doesn't slide objects, but moves them into holes.  With this kind of
> compaction it is very easy to leave objects put.
>
> A further advantage of Spur is that objects have 64-bit alignment so
> passing arrays to e.g. code using sse instructions, won't cause potential
> alignment faults.
>
>
> Not to be a drag, but SSE operations have 16-byte alignment requirement.
> With 8-byte aligmnent of first indexable slot, you'd still need to use
> aligned loads/stores.
>
> Cheers,
> Henry
>

Hi Henry, thanks.  That's potentially tedious to achieve because objects,
having either 8-byte or 16-byte headers, are not trivial to align such that
their first field is always on a 16-byte boundary.  But since we're only
talking about pinned objects in old space, it should be reasonably
straight-forward to add the constraint that pinned objects are so aligned.
 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.



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130925/31dcc202/attachment.htm


More information about the Vm-dev mailing list