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

[Eliot Miranda]

Hi Tim, Hi All,

On Wed, Sep 25, 2013 at 12:46 PM, tim Rowledge <tim at rowledge.org> wrote:

>
>
> 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.
>

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.


> 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 ;-)
>

That could work, but offends my sense of the separation between the system
and the VM.  So I don't feel like going there :-)


> 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.
>

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).

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