on non-static field layout

[Aleksey Shipilev]

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.


> 2. about filling gaps

...

> I believe we can allocate fields more densely (i.e. without
> unnecessary gaps in superclasses) with one pass (i.e. without
> sorting). When fields are aligned and packed densely, there can be
> zero or one 1-byte gap, zero or one 2-bytes gap and zero or one
> 4-bytes gap. So we can just keep track of these gaps and use them when
> occasion offers. E.g. when we need to allocate 2-byte field, first we
> try to use 2-bytes gap, otherwise we try to use 4-bytes gap (actually
> only the first half of it, the second half becomes 2-bytes gap),
> otherwise we append field to the end.

Note that converting 4-byte gap into 2-byte gap after field placement
invalidates the original invariant "When fields are aligned and packed
densely, there can be [...] zero or one 2-bytes gap", when there is
already a 2-byte gap.


Thanks,
-Aleksey