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

[tim Rowledge]

On 25-09-2013, at 11:36 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> On Wed, Sep 25, 2013 at 10:39 AM, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> On 25-09-2013, at 9:30 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> >  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.
> >
> 
> 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?
> 
> 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?

Almost always. But it's worth throwing wild ideas around occasionally just to see if they stick to the blanket.
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 ;-)

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.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: DMZ: Divide Memory by Zero