Master Thesis on Shenandoah

[Dominik Inführ]

Hi,

so I've analyzed heap dumps of IntelliJ, Eclipse and NetBeans. I've also
repeated the analysis on the JARs in my home directory:
https://paste.fedoraproject.org/paste/0C2inj5tDvYZoNq3l-8QfA

There are four alternatives:
1) No fwdptr
2) Fwdptr before the object
3) uncompressed fwdptr after object header (first field)
4) compressed fwdptr after object header

I've tested these 4 modes with alignment of 8, 16 and 32 bytes and
compressed/uncompressed oops. All sizes in the link are relative to 8-byte
alignment, compressed oops and no fwdptr.

Here is the DataModel I used for measuring sizes:
https://paste.fedoraproject.org/paste/vWp--180wJzeERL47Eueeg

Surprising for me was that there are no space savings for a compressed
fwdptr when using uncompressed oops (for the classes in my JAR files). The
reason for that is that each superclass (in this case java.lang.Object) is
aligned to the oop size (16 bytes header + 4 bytes fwdptr + 4 bytes padding
= 16 bytes header + 8 bytes fwdptr).

HotspotLayouter has options to use that space (takeHierarchyGaps or
takeSuperGaps), but they are not activated by default and I couldn't find
those options in the JDK. Nevertheless there are some space savings for the
heap dumps because of Arrays: the padding can be used by the length-field.

Do the numbers sound reasonable to you? Should I take heap dumps of other
applications as well? Since I basically analyzed 3 IDEs. Heap dump sizes
were all about 130MB.

Dominik

On Wed, Oct 18, 2017 at 10:32 PM, Dominik Inführ <dominik.infuehr at gmail.com>
wrote:

> On Wed, Oct 18, 2017 at 1:06 PM, Aleksey Shipilev <shade at redhat.com>
> wrote:
>
>> On 10/16/2017 09:26 PM, Dominik Inführ wrote:
>> > I want to give a short update: I've changed JOL a bit such that it
>> emits the class/instance-size for
>> > both the variant with the compressed fwdptr and the uncompressed
>> fwdptr. All I did was to reuse the
>> > HotspotLoader from JOL with a new data model subclassed from
>> X86_64_COOPS_Fwdptr_DataModel. The data
>> > model adds either 4 (for compressed fwdptr) or 8 (for the uncompressed)
>> to the header size.
>>
>> Ah, there is a caveat: extending the header size is probably not in line
>> with what we would do with
>> fwdptr storage. That is, extending the header would need to include the
>> internal alignments for
>> fwdptr, e.g. this is wrong:
>>
>> 0:  [header]
>> 12: [8-byte fwdptr] // alignment is broken
>>
>> I think we have to simulate the "injection" of fwdptr as the field in
>> java/lang/Object to make it
>> the subject of alignment constraints. So, there are four cases:
>>
>>  a. No fwdptr
>>  b. 8-byte fwdptr before the object (that can indeed be modelled with
>> adding +8 to header)
>>  c. 8-byte fwdptr as the field
>>  d. 4-byte fwdptr as the field
>>
>
> So I guess I've tested the cases a), b) and d).
>
> I actually thought about c) but disregarded it, since it was harder to
> implement :D but also because it could only make things worse. But I guess
> it might be beneficial for ObjectAlignmentInBytes > 8. It may already be
> good enough to simulate this field by writing the header something like
> this:
>
> int headerSize() { return align(super.headerSize(), 8) + 8; }
>
> I guess I really should get some numbers for compressed/uncompressed oops
> for different alignments.
>
>
>>
>> > With this I can compare class/instance-sizes for e.g. all the JARs in
>> my home directory (about
>> > 114,000 classes). I just summed up all class sizes for each of the 3
>> variants (no fwdptr,
>> > uncompressed fwdptr, compressed fwdptr), each class is counted once:
>> Classes with an uncompressed
>> > fwdptr have in total 22.7% overhead over those same classes with no
>> fwdptr (11.4% for compressed
>> > fwdptr's). 70% of the classes seem to be smaller with a compressed
>> fwdptr compared to the same class
>> > with an uncompressed fwdptr.
>>
>> Okay, nice piece of data! Now we need to figure out what are the most
>> popular object shapes around
>> real Java applications -- try to process some heapdumps for the Java
>> applications you have? Parsing
>> Maven Central is overkill at this point.
>>
>
> I was actually hoping that you would tell me this is overkill ;) I will
> try to find some and take a heap dump of them.
>
> Thank you very much for the feedback!
>
> Dominik
>
>
>>
>> -Aleksey
>>
>>
>