Master Thesis on Shenandoah

[Dominik Inführ]

I added the heap numbers and the data model into a gist:
https://gist.github.com/dinfuehr/e01b089d2edc3e26324e98ee61752b90. The
paste.fedoraproject.org-links were only valid for one week.

Dominik

On Tue, Oct 31, 2017 at 7:35 AM, Dominik Inführ <dominik.infuehr at gmail.com>
wrote:

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