on non-static field layout

[Remi Forax]

On 02/16/2015 10:23 PM, Dmytro Sheyko wrote:
> 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.

Heap dump is one scenario, but it's not the only one where you want to 
traverse a part of the heap.
If you want to implement a GC that does card-marking, you need to be 
able to traverse the zone of the heap corresponding to a marked bit and 
because usually a bit cover several objects you need a way to traverse 
the heap to find the references that goes from old gen to new gen.

>
> Thanks,
> Dmytro

Rémi

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