[FFI] Pointer arithmetic impossible on ByteArray?

Now playing with FFI, i really appreciate to be able to handle memory in a
Smalltalk space, with a ByteArray.

Unfotunately, one little thing lack on ByteArray: pointer arithmetic.

I'd like to pass an address kind of (aByteArray baseAdress + 4) to a FFI CALL
for example...

I can do that right now with external heap (ExternalAddress new fromInteger:
anAddress asInteger + 4), but not with Smalltalk-space.

Maybe an IndirectByteArray could be added to the FFI plugin?

This would be really cool.

Nicolas

Not a chance. The "base address" of an object isn't constant; the object
will be moved by a GC and therefore you simply can't guarantee that "foo
baseAddress" is a meaningful value for any period of time other than  in
the primitive call itself (even the return from the primitive could
cause a process switch, which could cause GC somewhere, which could move
the object, which invalidates the base address).

Cheers,
   - Andreas

nicolas cellier wrote:

Le Samedi 20 Mai 2006 02:30, Andreas Raab a écrit :
> Not a chance. The "base address" of an object isn't constant; the object
> will be moved by a GC and therefore you simply can't guarantee that "foo
> baseAddress" is a meaningful value for any period of time other than  in
> the primitive call itself (even the return from the primitive could
> cause a process switch, which could cause GC somewhere, which could move
> the object, which invalidates the base address).
>
> Cheers,
>    - Andreas

Of course, i want it in a primitive to avoid this kind of problem.
Is a plugin immune to that kind of moving GC ?

Nicolas

nicolas cellier wrote:
But even if it's in a primitive, it's no longer immune from GC when you
return from it. So you can neither return "foo baseAddress" or "foo
baseAddress+X" from a primitive in a meaningful way.  You'd have to do
the pointer calculation and the call from the same primitive at which
point you're in plugin (and not FFI) land. And yes, in a plugin you can
do that just fine.

> Is a plugin immune to that kind of moving GC ?

No, of course not. You can't keep references to objects across primitive
calls for example. Inside primitive calls it depends on what the
primitive does - various operations (like allocation) may cause GC and
an oop you referred to before the GC will be no longer valid after it
unless you explicitly remap it.

Cheers,
   - Andreas

Le Samedi 20 Mai 2006 03:03, Andreas Raab a écrit :

> > Of course, i want it in a primitive to avoid this kind of problem.
>
> But even if it's in a primitive, it's no longer immune from GC when you
> return from it. So you can neither return "foo baseAddress" or "foo
> baseAddress+X" from a primitive in a meaningful way.  You'd have to do
> the pointer calculation and the call from the same primitive at which
> point you're in plugin (and not FFI) land. And yes, in a plugin you can
> do that just fine.
>

No, i do not want to handle baseAddress in Smalltalk, because i do not care of
absolute address in memory.

What i want is to play with relative memory offset.
If all the pointer arithmetic baseAddress+byteOffset goes into the plugin,
that's fine!

I just want to be able to pass an object (IndirectByteArray?) to a FFI call so
that i can play with memory offset inside ByteArray as i can already play in
external heap.

For example, i would use a memcpy to implement some kind of
replaceFrom:to:with:startingAt:, what i have now working with ExternalAdress,
but not with ByteArray (except startingAt: 1).

Well, I suppose one must care of order of operations when writing a plugin.
Must be tricky sometimes...

Nicolas

nicolas cellier wrote:
> I just want to be able to pass an object (IndirectByteArray?) to a FFI call so
> that i can play with memory offset inside ByteArray as i can already play in
> external heap.

Well, good luck then. That's far from trivial.

>>> Is a plugin immune to that kind of moving GC ?
>> No, of course not. You can't keep references to objects across primitive
>> calls for example. Inside primitive calls it depends on what the
>> primitive does - various operations (like allocation) may cause GC and
>> an oop you referred to before the GC will be no longer valid after it
>> unless you explicitly remap it.
>
> Well, I suppose one must care of order of operations when writing a plugin.
> Must be tricky sometimes...

Yes, it is. And people get it wrong quite a bit, which is why I have
proposed to turn off GC alltogether in primitive calls to avoid these
issues. That raises some other problems though, such as what to do when
a plugin requests a large object and the VM can't accommodate the
request without GC etc.

Cheers,
   - Andreas