[master] RFR: Read class from object header

[Dave Dice]

On 2021-9-16, at 6:52 AM, Roman Kennke <rkennke at openjdk.java.net<mailto:rkennke at openjdk.java.net>> wrote:

On Thu, 5 Aug 2021 19:42:23 GMT, Dave Dice <dave.dice at oracle.com<mailto:dave.dice at oracle.com>> wrote:

The following ? ?Compact Java Monitors? -- might provide some relief : https://arxiv.org/pdf/2102.04188.pdf.

As described, it handles just the identity hashCode value, but it?s trivial to extend the idea to displacing the whole lilliput header word.

Thanks, Dave! I will study it!
My current thinking wrt identityHashcode is to not store it in the header at all, but instead append it to the object on-demand. That is, when identityHashCode() is called, it would get re-computed as long as the object does not move, and as soon as it moves, an extra field would get appended to the object (or rather, often it fits in alignment gap at the end), and the hashcode is installed there. This is implemented in prototype here: https://github.com/rkennke/lilliput/tree/compact-hashcode

Hi Roman,

I looked through compact-hashcode and, if I’m reading the definitions of “hashctrl” correctly, this appears to be the tri-state (2-bit) hashCode algorithm from Bacon et al. : https://doi.org/10.1007/3-540-47993-7_5.  If that’s actually the case, it’d likely be good to include a citation in the code.   It was a good idea 20 years ago, and remains a good idea.   The only downside I know of is that you can exhaust memory extending objects in a moving GC, but there are ways to guard against that condition.

The Compact Java Monitor approach is rather agonistic concerning the hashCode (and for that matter, anything else in the header, such as the class/klass information, and age bits).   If you use the IBM 2-bit scheme, that’s fine, and if you need to displace it, that’s fine as well.

I hope to send out some results next week comparing the relative performance of a few potential “synchronized” implementations.


Regards
Dave










But, as far as I can see, it doesn't help with the problem that concurrent GCs have with the thread-locks.

-------------

PR: https://git.openjdk.java.net/lilliput/pull/12