Master Thesis on Shenandoah

[Aleksey Shipilev]

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