RFR[L]: 8237767 Field layout computation overhaul

[Frederic Parain]

Aleksey,

Thank you very much for your experiments and the help you gave me.

Here’s a new version of the code addressing these regressions:
http://cr.openjdk.java.net/~fparain/jdk_layout/webrev.09c/index.html

An incremental webrev is available here:
http://cr.openjdk.java.net/~fparain/jdk_layout/webrev.09c-diff/index.html

Changes are mostly in src/hotspot/share/classfile/fieldLayoutBuilder.cpp:

line 68-71: bug fix

line 171-200: replace the first-fit search with a best-fit search

line 394-395: bug fix

line 613: replace bulk allocation of reference fields with individual allocations

Remaining changes are cleanup from the change in line 613.

Regards,

Fred


> On Feb 3, 2020, at 13:15, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> On 2/3/20 5:33 PM, Aleksey Shipilev wrote:
>> As I look through the layouter going through my local Maven Central snapshot, this case does not
>> look rare for us not to care. Looks like every class with a long and 3+ oop fields is regressing in
>> instance size, which is in line with your explanation. I believe this needs to be resolved before
>> releasing the new layouter in the wild.
> 
> To add some more data, out of ~15M classes, about 14K (~0.01%) are affected:
>  https://cr.openjdk.java.net/~shade/8237767/classes-regression-1.txt
> 
> Of course, this does not mean we would have 0.01% footprint regression, because we don't know how
> many instances of the affected class would be present. But browsing the list, it looks like plenty
> of data classes, iterators, etc present.
> 
> For fun, here is some friendly fire: org.openjdk.tools.javac.code.Symbol -- it has long
> Symbol.flags_field and plenty of oop fields.
> 
> -- 
> Thanks,
> -Aleksey
>