RFR[L]: 8237767 Field layout computation overhaul

[Frederic Parain]

Hi Aleksey,

Thank you for reporting this issue.

There’s definitively a regression if the layout of this class.

The cause of this regression is the way the new algorithm allocates
reference fields: it looks for a space big enough to allocate them
contiguously (so there’s a single oopmap for all oops declared in
the current class, and less work for the GC to find these oops).

An unfortunate side effect of this strategy is that some unused slots
big enough to store one or several oops are not considered as valid
candidates because they cannot contain all oops.

In the case you spotted, the abstract class has a long field and
eight reference fields. The long field is allocated first, because
of its size, creating a gap between the end of the header (with a
compressed class pointer) and this first field. Then, the new algorithm
tries to allocate the eight reference fields contiguously and look
for a space big enough, and ignore this gap because it can only contain
one oop.

The story repeats itself with the sub-class which has a double field
and twelve reference fields. The double field doesn’t fit in the gap,
and the code tries to allocate all reference fields contiguously, ignoring
the possibility to store an oop in this gap.

A possible fix for this issue would be to drop the contiguous allocation of
oops.

Regards,

Fred



> On Feb 3, 2020, at 07:07, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> Hi again,
> 
> On 1/31/20 5:03 PM, Frederic Parain wrote:
>> New webrev:
>> http://cr.openjdk.java.net/~fparain/jdk_layout/webrev.08/index.html
> 
> I have been running new layouter (at webrev.08) with the collection of class files I have around,
> and I believe there is a instance size regression. Look here:
>  https://cr.openjdk.java.net/~shade/8237767/regression-1.txt
> 
> -- 
> Thanks,
> -Aleksey
>