<div dir="ltr"><br><div class="gmail_extra">if we started about ideas..<br><br></div><div class="gmail_extra">what about good-old indirection? :)<br><br>we could use extra object format with indirection to its data, with following layout:<br>
</div><div class="gmail_extra"><header bitOr: PINNED><data pointer><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">so, the data (only for variable bytes, not var-references, of course) associated with such object can be located in separate non-movable region<br>
and you need to do extra work when scavenging objects with such special format,<br></div><div class="gmail_extra">but for the rest, it almost the same:<br></div><div class="gmail_extra"> - the object (oop) itself can still move in memory, no big deal since its data pointer remains the same<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">extending the idea, we could have even objects which pointing inside of an object..<br></div><div class="gmail_extra">like with Nicolas'es unboxed complex numbers,<br>
</div><div class="gmail_extra">i could say: i want an object which points to imaginary field of unboxed complex value.<br></div><div class="gmail_extra">so the complex value can be represented as a pinned object big enough to hold 2 floats:<br>
<br><div class="gmail_extra"><header bitOr: PINNED><data pointer to 2 64-bit floats><br></div><div class="gmail_extra"><br></div>and the object representing an imaginary float part can be following:<br></div><div class="gmail_extra">
<br><div class="gmail_extra"><header bitOr: PINNED-SLAVE><complex oop><data pointer + 8><br></div><div class="gmail_extra"><br></div>the main difference between PINNED and PINNED-SLAVE,<br></div><div class="gmail_extra">
that during scavenging, GC will ignore and won't deallocate the buffer pointed to by the slave,<br></div><div class="gmail_extra">that's why it holds a reference to its master (<complex oop> in the example)<br>
to prevent deallocation/garbage collection of master and allocated buffer.<br><br></div><div class="gmail_extra">in fact, PINNED-SLAVE format can be used for pointing in memory to anything (even outside<br>memory managed by GC, because it never (de)allocates that memory),<br>
</div><div class="gmail_extra">like that i can easily represent some data blob/buffer provided by external library as ByteArray<br>object in image:<br><br><div class="gmail_extra"><header bitOr: PINNED-SLAVE><nil><buffer pointer><br>
</div><div class="gmail_extra"><br></div></div><div class="gmail_extra"><br clear="all">-- <br>Best regards,<br>Igor Stasenko.
</div></div>