Master Thesis on Shenandoah

[Dominik Inführ]

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