RFC: Move forwarding ptr into the object

[Aleksey Shipilev]

Hi,

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.

Observations:

  *) Shenandoah asserts are rather nice. I made the the BrooksPointer
more asserty about the forwarding pointers, which helped me to catch a
few bugs along the way.

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

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

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

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?

Thanks,
-Aleksey