[Vm-dev] [Pharo-dev] [NB] Trying to implement a ReadStream on
eliot.miranda at gmail.com
Wed Sep 25 22:28:09 UTC 2013
On Wed, Sep 25, 2013 at 2:56 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:
> Alignment apart, one thing that could be useful is the ability to pass the
> address of a byte array, offsetted at will.
> For example, I have an array of unboxed double complex
> And I want to copy the imaginary part only in another location.
> Blas provides enough methods for that, I just need to pass
> - ByteArray adress+8 bytes (+1 sizeof double)
> - half array length
> - and a stride of 16 bytes (2 size of double).
> In most Smalltalk dialects, this is currently only possible with External
> Heap, but not with Smalltalk managed memory...
> OK, some guru will tell me to do it with BitBlt, but ther must be
> something easier...
> I feel like this would open many possibilities for interpreting low level
> (like invoking some primitives on emulated memory blob).
Yes, good idea. David Leibs proposed this for DLLCC a while back and I
implemented it even though IIRC there's no image-level support for this.
It's easy to add to FFI argument parsing. Consider it on the list, but
you could remind me and/or Igor when we revisit the ThreadedFFI &
NativeBoost once Spur is functional.
> 2013/9/25 Eliot Miranda <eliot.miranda at gmail.com>
>> 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>
>>> > On Wed, Sep 25, 2013 at 10:39 AM, tim Rowledge <tim at rowledge.org>
>>> > 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