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

[Eliot Miranda]

Hi Nicolas,


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
> (real0,imaginary0,real1,imaginary1,...)
> 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
> languages
> (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>
>>> 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
>>
>>
>
>


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