Master Thesis on Shenandoah

[Dominik Inführ]

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.

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.

I wanted to get some feedback whether this is the analysis you actually had
in mind before I try to download & analyze maven-central as you proposed.
It might also be interesting to get those numbers for heap dumps in some
specific workloads.

Thanks
Dominik

On Fri, Oct 6, 2017 at 8:19 PM, Aleksey Shipilev <shade at redhat.com> wrote:

> Hi Dominik, and welcome!
>
> On 10/05/2017 10:29 PM, Dominik Inführ wrote:
> > I am interested in working on Shenandoah as part of my master thesis at
> the
> > University of Technology in Vienna. Aleksey mentioned in his VMM-Talk in
> > Prague a possible project: storing the Brooks indirection pointer in the
> > object header.
>
> Yes, our initial experiments with JOL [1] told us we can save quite some
> space, if we are able to
> compress the fwdptrs. I think experimenting with JOL first, and only then
> going into Hotspot land
> would be quicker and less traumatic for the beginner.
>
> Some technical background follows.
>
> Current fwdptr machinery allocates the HeapWord-wide slot before
> allocating the Java object [3].
> That slot is 8-byte wide on 64-bit JVM, and there is a full-width fwdptr
> there. This mechanics is
> simple, it enables the constant offset for fwdptrs, but it comes with the
> caveat. No change in
> fwdptr representation would not help memory footprint, because the _object
> itself_ should be
> allocated with 8-byte alignment [4]. Which means, the allocation machinery
> is bound to allocate the
> 8-byte slot anyway to keep that alignment intact.
>
> The situation changes when we move fwdptr into the object itself. The
> simpler thing would be to move
> it to the field block, at the constant offset, e.g. right after the
> header. If fwdptr is still be
> 8-byte long and still be 8-byte aligned, there is no win (or maybe I am
> blind?): it would not
> disturb the alignment of object fields, and will just move some fields by
> 8 bytes. This means total
> object footprint would not improve.
>
> But, we know that heap pointers can be compressed [2]. Fwdptr is
> technically a heap pointer, and
> thus it can be similarly compressed, which reuses lots of already existing
> code. There is a caveat
> for compressed fwdptrs: access through them may end up prohibitively
> expensive, because additional
> unpacking would be needed on each read barrier. However, if that is
> successful, having a 4-byte
> fwdptr within the fields block should be a footprint win.
>
> So, there are a few research tasks with increasing level of complexity,
> and natural progression:
>  a) Study the field layouts and object footprint in Hotspot (probably just
> walking through JOL Samples);
>  b) Use JOL to model the overheads for current fwdptr placement scheme,
> identify problematic object
> shapes, correlate them with real-world shapes (e.g. parsing the entire
> Maven Central! ;)
>  c) Use JOL to model the overheads for different alternative fwdptr
> placement schemes, and estimate
> their potential space improvements;
>  d) Try to turn fwdptrs into compressed without changing the placement
> scheme, estimate the barriers
> costs with new compressed scheme;
>  e) If successful, implement one of the alternative fwdptr placement
> schemes;
>  f) If successful, review and push the entire thing into OpenJDK/Shenandoah
>
> Are you up for it?
>
> HTHS,
> -Aleksey
>
> [1] http://openjdk.java.net/projects/code-tools/jol/
> [2] https://wiki.openjdk.java.net/display/HotSpot/CompressedOops
> [3]
> http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/file/
> c979dd32d10e/src/share/vm/gc/shared/collectedHeap.inline.hpp#l199
> [4]
> http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/file/
> c979dd32d10e/src/share/vm/runtime/globals.hpp#l590
>
>