on non-static field layout

[John Rose]

On Feb 16, 2015, at 6:58 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
>>> What about if reference fields were allocated BEFORE header (with
>>> negative offset)? In this case they all would form single solid
>>> cluster. Maybe we wouldn't need oop_map at all, knowing just number of
>>> reference fields would be enough.
>> AFAIU, placing anything before the object header is hard at best. I am
>> not completely sure HotSpot machinery can be reliably modified for
>> allocating the arbitrary number of fields before the header. E.g,
>> handling all the cases where the header is at non-zero offset would
>> require point changes in many places in VM.
>> 
>> Either way, I don't see the offhand benefit of doing this: it does not
>> improve footprint, and only (possibly) improves the heap scanning during
>> GC. But then again, stepping *back* in memory after reading the header
>> can be more expensive than just doing the forward jumps over the oop
>> regions.


In Maxine terms [1] Dmytro is talking about a scheme that could be called "ROHP" (references, origin, header, primitives).

[1] https://wikis.oracle.com/display/MaxineVM/Objects

This scheme would favor those few objects which have complex oop maps.  But it might confuse HW prefetchers, heap scanners, debug tools, etc.  And it would not help most objects, which do not have complex oop maps.

It would be better IMO to invest work in compiling customized oop-tracing loops for common oop-map syndromes.  (I.e., 0, 1 at N, 2 at N, 3 at N, M at N, 1 at 8, 1 at 12, 1 at 16, etc.)

> a stupid question but how do you scan the heap from start to end if you have an unknown number of references in front of the header of an object ?

Either prefix the sequence of oops with a pre-header word, or else make sure any object header is always a distinct bit pattern from any oop.  (This is mostly true in the non-compressed-oop VM, since mark words often have a low-tag bit of 1.)

— John