rkennke at redhat.com
Wed May 4 16:15:22 UTC 2022
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.
- 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:
Or by trying one of Aleksey's nightly builds (they are following master
branch, though, so will eventually drift away from the tag):
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
Red Hat GmbH, Registered seat: Werner von Siemens Ring 14, D-85630
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy
More information about the lilliput-dev