on non-static field layout

[Remi Forax]

On 02/16/2015 03:33 PM, Aleksey Shipilev wrote:
> Hi,
>
> I think both improvements should be implemented separately. Even the
> basic implementation would be complicated enough to cause some
> improvements in the existing code, before making the intrusive change.
>
>
> On 02/16/2015 11:04 AM, Dmytro Sheyko wrote:
>> 1. about reference fields
>>
>> I can see that reference fields are tried to be laid out together.
>> Moreover reference fields of subclass can be appended to the pack of
>> reference fields of its superclass, reducing number of oop_map entries
>> (especially when -XX:FieldsAllocationStyle=2). However reference
>> fields can still be scattered throughout the object and oop_map can
>> have more than 1 entry.
>>
>> 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.

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 ?

Rémi