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