[master] RFR: Read class from object header
dave.dice at oracle.com
Thu Sep 16 17:16:47 UTC 2021
On 2021-9-16, at 1:01 PM, Roman Kennke <rkennke at openjdk.java.net<mailto:rkennke at openjdk.java.net>> wrote:
On Thu, 16 Sep 2021 16:43:30 GMT, Dave Dice <dave.dice at oracle.com<mailto:dave.dice at oracle.com>> wrote:
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.
That is likely true. I can't access the paper, though, it asks me to pay 26€ ;-) I haven't read the paper, I've adopted the algorithm from talking to an OpenJ9 guy - OJ9 apparently uses a similar algorithm (haven't looked at their code, either).
Here’s a non-paywall version of the paper hosted by IBM :
It remains a good read.
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.
Right. It can't happen with sliding GCs, but copying GCs could theoretically run into this problem. It seems very very unlikely, but not impossible.
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.
I am a bit unsure about which direction to go. I also heard that there is work under way to remove JVM-side locking altogether, and use j.u.c instead, which would make the whole displaced-header problem go away. Getting rid of displaced headers would be a huge win. Otherwise we'll have to come up with a way to deal with it in concurrent GCs.
I think the loom folks are certainly interested in replacing synchronized with ReentrantLock-like constructs to avoiding the current pinning of virtual threads to threads.
I’ve experimented (mostly outside the JVM but in a fairly faithful C++ simulacrum) with a number of ideas, all the way from approaches that don’t touch the header at all (aesthetically desirable, but costly) to ones that borrow just a few bits of the header, to ones that still use displacement, but make accessing the displaced value much more sane (CJM). As noted, I hope to send out a rough paper with some data next week.
More information about the lilliput-dev