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

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

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

Nicolas