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

Igor Stasenko siguctua at gmail.com
Thu Sep 26 14:40:17 UTC 2013


if we started about ideas..

what about good-old indirection? :)

we could use extra object format with indirection to its data, with
following layout:
<header bitOr: PINNED><data pointer>

so, the data (only for variable bytes, not var-references, of course)
associated with such object can be located in separate non-movable region
and you need to do extra work when scavenging objects with such special
format,
but for the rest, it almost the same:
 - the object (oop) itself can still move in memory, no big deal since its
data pointer remains the same

extending the idea, we could have even objects which pointing inside of an
object..
like with Nicolas'es unboxed complex numbers,
i could say: i want an object which points to imaginary field of unboxed
complex value.
so the complex value can be represented as a pinned object big enough to
hold 2 floats:

<header bitOr: PINNED><data pointer to 2 64-bit floats>

and the object representing an imaginary float part can be following:

<header bitOr: PINNED-SLAVE><complex oop><data pointer + 8>

the main difference between PINNED and PINNED-SLAVE,
that during scavenging, GC will ignore and won't deallocate the buffer
pointed to by the slave,
that's why it holds a reference to its master (<complex oop> in the example)
to prevent deallocation/garbage collection of master and allocated buffer.

in fact, PINNED-SLAVE format can be used for pointing in memory to anything
(even outside
memory managed by GC, because it never (de)allocates that memory),
like that i can easily represent some data blob/buffer provided by external
library as ByteArray
object in image:

<header bitOr: PINNED-SLAVE><nil><buffer pointer>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130926/8ee4a3d2/attachment.htm


More information about the Vm-dev mailing list