[PATCH] 7901019: jol estimates do not take AllocationStyle into the account

[Тимур Гибадуллин]

I haven't mentioned, currently Hotspotlayouter does not handle 
takeHierarchyGaps and takeSuperGaps while lauouting. I will add them 
very soon.

On 02.07.16 2:14, Тимур Гибадуллин wrote:
> Thanks! Fixed this, have changed the layouting algorithm to working on 
> fields of each class in isolation, also added proper handling of the 
> second allocation style.
>
>
> On 06.06.16 19:22, Aleksey Shipilev wrote:
>> Hi,
>>
>> On 06/06/2016 12:47 AM, Тимур Гибадуллин wrote:
>>> Hey there! I fixed tests, there were several bugs during determining
>>> allocation types of java types, also I removed autoAlign option from
>>> HotspotLayouter, because it seems, that now it is unnecessary, since we
>>> emulate original Hotspot algorithm of layouting.
>> Actually, autoAlign is needed to allow layout simulation (same with
>> take{Hierarchy|Super}Gaps). HotspotLayouter in default mode should match
>> the current VM layout precisely.
>>
>> I have corrected a few things in the patch, and added a new tests that
>> matches the actual VM layout against HotspotLayouter:
>> http://cr.openjdk.java.net/~shade/7901019/AllocationStyle-v2.patch
>>
>> This identified at least one bug: new code takes all fields from the
>> entire hierarchy, and lays them out. This is not how a real layouter
>> works: it works on fields of each class in isolation.
>>
>> Actual layout:
>>
>> Class9943 object internals:
>>   OFFSET  SIZE    TYPE DESCRIPTION                    VALUE
>>        0    12         (object header)                N/A
>>       12     1 boolean Class9942.field0               N/A
>>       13     3         (alignment/padding gap)        N/A
>>       16     8  double Class9943.field0               N/A
>>       24     2   short Class9943.field1               N/A
>>       26     6         (loss due to the next object alignment)
>> Instance size: 32 bytes
>> Space losses: 3 bytes internal + 6 bytes external = 9 bytes total
>>
>> VM Layout Simulation (current, field allocation style: 2)
>> Class9943 object internals:
>>   OFFSET  SIZE    TYPE DESCRIPTION                    VALUE
>>        0    12         (object header)                N/A
>>       12     4         (alignment/padding gap)        N/A
>>       16     8  double Class9943.field0               N/A
>>       24     2   short Class9943.field1               N/A
>>       26     1 boolean Class9942.field0               N/A
>>       27     5         (loss due to the next object alignment)
>> Instance size: 32 bytes
>> Space losses: 4 bytes internal + 5 bytes external = 9 bytes total
>>
>> Notice how Class9942 field is laid out after all field in patched
>> HotspotLayouter. This is incorrect. Once you fix that,
>> take{Hierarchy|Super}Gaps gain meaning: hierarchy gap is a gap due to
>> "next class field block" alignment, and super gap is the hole left in
>> superclass after layout, that may be used to put some subclass fields.
>>
>> Thanks,
>> -Aleksey
>>
>