There is a caveat the article doesn't mention, it's not possible to use both synchronized/lock elision and System.identityHashCode. The 4bytes in the object header are either used for the hashCode or the threadId(not java.lang.Thread.getId()), holding the monitor. +2 control bits.

Also the stuff has not changed for the past... 14y or so. It's pretty old news.

It's changing now https://wiki.openjdk.java.net/display/lilliput

Can you clarify what is not possible or provide a link please?

I haven't heard of this, and don't understand what you said well enough to google it myself.

That's an article[0] from Dave Dice (a quick search for "biased lock java hashCode header)

Edit: Found a copy[1] of the early Cliff Click's blog... For whatever reasons google doesn't have it listed (so I typed the url. cliffc.org is empty as well.. Other than that Java's hotspot source is available too.

[0]: https://blogs.oracle.com/dave/biased-locking-in-hotspot

[1]: https://www.h2o.ai/blog/biased-locking/

Thanks!

So am I correctly understanding this as:

Using identityHashCode() does not prevent locks from working, it merely prevents the performance optimization of biased locking (which Java 15 disables by default anyway)?

Something like that. The biased locking is an overall a software fix for a hardware shortcoming, notably CAS being slow (and need for a fence on the read part, but that's pretty much free on the most of the hardware nowadays).

Lack of biased locking could be quite detrimental to CHM wide use. OTOH it'd mean a smaller header/memory footprint, which is nice.

If you are interested in the Java internals Cliff Click's (who is the original hotspot architect) insights of a decade ago will worth your while.