on non-static field layout

[Dmytro Sheyko]

Hi Remi,

Having pointer to object (which is pointer to header actually) we are
able to access information about its class and hence field layout
(including information about number of ref fields that are allocated
before header). Thus we could access all other objects that are
referenced from it.

However if you are talking about iterating over all objects in heap
(live and dead), for example, for head dump, then you are right, we
would not be able to do this. I don't have good ideas for now.

Thanks,
Dmytro

On Mon, Feb 16, 2015 at 4:58 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
> 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
>