Master Thesis on Shenandoah

[Aleksey Shipilev]

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

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

-Aleksey