RFC: Move forwarding ptr into the object

[Roman Kennke]

Hi Aleksey,

> Since last afternoon I've been playing with moving the forwarding ptr
> into the object itself. This proved a more or less straightforward
> thing
> to do, here is a prototype:
>   http://cr.openjdk.java.net/~shade/shenandoah/inline-ptr/webrev.00/
> 
> This is not a "production-ready" patch. But, it runs interpreter, C1,
> C2
> almost fine. Humongous object tests fail the new asserts, but that is
> probably because my new asserts are to restrictive.

Great work! Some comments...

> 
> 
>   *) The filler object mechanics is now gone, but we trade in the
> proper
> header initialization on all paths. Some code in VM (JVM_Clone,
> looking
> at you!) actually copies the entire object with header *after* we
> setup
> the forwarding ptrs.

Is that a problem?

>   *) OOP definition in VM is static, and some artistry would be
> required
> to make sure the header has the forwarding ptr only for Shenandoah.

The forwarding ptr must not be static in the sense that other GCs would
get it too. But it should be possible to treat it as an extra slot only
for Shenandoah. Kindof like the length field of arrays is handled now.

>   *) Forwarding ptr should probably be inlined between the mark word
> and
> class word: a) mark word is always HeapWord-sized, so forwarding ptr
> is
> always HeapWord-aligned, regardless of class ptr compression; b) some
> code in VM thinks the header size is the
> offset_of(class_ptr)+sizeof(class_ptr)...

I was thinking that maybe it should be placed between the klass* and
the actual fields:
1. we never need a read-barrier for reading the klass* and rarely (if
ever) for the mark word, this would 'widen the window' for possible
cache hit for subsequent field reads.
2. We may be able to squeeze the compressed forwarding ptr after the
compressed klass* for non-arrays (assuming we can handle/compile
different offsets for objects vs. arrays.

But we can figure out the exact best placement later (based on
benchmarks)

> But in the end, this is what it for: the forwarding ptr is now being
> accounted in the instance size, *and* this makes it immune to
> ObjectAlignmentInBytes, *and* this opens the way to compress
> forwarding
> ptrs (making an optional tradeoff between the footprint and the cost
> of
> read barriers).


> 
> $
> ~/trunks/shenandoah-jdk9/build/linux-x86_64-normal-server-
> fastdebug/images/jdk/bin/java
> -XX:+UseShenandoahGC -jar jol-cli/target/jol-cli.jar internals
> java.lang.Object
> # Running 64-bit HotSpot VM.
> # Using compressed oop with 3-bit shift.
> # Using compressed klass with 3-bit shift.
> # Objects are 8 bytes aligned.
> # Field sizes by type: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]
> # Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]
> 
> Instantiated the sample instance via default constructor.
> 
> java.lang.Object object internals:
>  OFFSET  SIZE  TYPE DESCRIPTION        VALUE
> ; mark word:
>       0     4       (object header)    05 00 00 00 ...
>       4     4       (object header)    00 00 00 00 ...
> ; forwarding ptr:
>       8     4       (object header)    48 fc 1f d0 ...
>      12     4       (object header)    05 00 00 00 ...
> ; compressed class word:
>      16     4       (object header)    ee 01 00 f8 ...
>      20     4       (loss due to the next object alignment)
> Instance size: 24 bytes
> Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
> 
> 
> Should we continue?

I like it, and would love to see it finished!

Roman