[Vm-dev] [Pharo-dev] [NB] Trying to implement a ReadStream on
eliot.miranda at gmail.com
Wed Sep 25 20:18:37 UTC 2013
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>
> > > 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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev