Milestone 1

[Roman Kennke]

Hi all,

I would like to announce that Lilliput reached an important milestone: 
64bit sized object headers. :-)

Currently, in upstream JDK, objects in the Java heap have 96 bits of 
header (or even 128 when running with -XX:-UseCompressedClassPointers): 
64 bits for the mark-word (which is multi-purpose, covering lock-bits, 
pointers to stack-locks or object monitors, GC age bits, GC forwarding 
pointer and identity hashcode) and 32 or 64 bits for compressed Klass* 
pointer (possibly compressed).

This milestone of Lilliput merges the mark-word and the Klass* into a 
single 64bit word, thus saving ~32bit (or 64bit with CCPs) per object. 
In order to do so, we turn on class-pointer-compression unconditionally, 
and put the 32bit Klass* into the upper 32bits of the object header. 
This means we need to coordinate with synchronization subsystem and the 
GC in order to read the correct header in case the object header has 
been displaced by a stack-lock, object monitor or GC forwarding pointer. 
Any code that loads the Klass* now needs to check for such situation (by 
checking the lock-bits) and carefully extract the Klass* if it is the case.

Caveats:
- The identity hashcode is currently limited to 25bits. That is so that 
we can fit everything into the header. The next milestone will handle 
the identity hashcode entirely differently, requiring only 2 bits in the 
header, and allowing 32bits (or more, if we wanted) for the actual hashcode.
- The serviceability agent is not supported. It would have to deal with 
header overloads to get to the Klass*, and I did not want to bother with 
that, especially given that I intend to get rid of the overload entirely 
- then this problem with disappear.
- Only x86_64 and aarch64 are supported. x86_32 should work, but don't 
behave any differently (mark-word and Klass* are already 32bits there, 
that makes 64bit together).
- Some array types don't benefit from the improvement, due to alignment 
restrictions. That is double[], long[] and Object[] (when running 
without compressed oops). In other words, all 64bit array element types 
need to be aligned to 64bit addresses, and thus cannot use the extra 
32bits free space after 64bit header and 32bit array length.

You can grab the milestone 1 by checking out the lilliput-milestone-1 
tag, and build that yourself:
https://github.com/openjdk/lilliput/tree/lilliput-milestone-1

Or by trying one of Aleksey's nightly builds (they are following master 
branch, though, so will eventually drift away from the tag):
https://builds.shipilev.net/openjdk-jdk-lilliput/

Let us now how it goes!


Huge thanks go to everybody involved, be it by contributing code, 
discussions, reviews, infrastructure, etc.


We are already working on next milestone, which will be 32bit headers :-D

Cheers,
Roman


-- 
Red Hat GmbH, Registered seat: Werner von Siemens Ring 14, D-85630 
Grasbrunn, Germany
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy 
Ross