on non-static field layout

[Dmytro Sheyko]

Hi Alexey,


On Mon, Feb 16, 2015 at 4:33 PM, Aleksey Shipilev
<aleksey.shipilev at oracle.com> 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.
>

I agree with you that these improvements should be implemented
separately, especially taking into account that allocating fields
before header may require more efforts that I expected initially and
would not be worth doing at all. Also I wonder what are real benefits
of grouping reference fields? How much would we lose if we allocate
reference fields among primitive ints or longs?


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

No. We convert 4-byte gap into 2-byte gap only if there is no 2-byte
gap. When 2-byte gap is present, we just use it. If you don't mind, I
will try to express this algorithm as JOL Layouter, in order to be
able to play with it.

Thanks,
Dmytro