[master] RFR: Read class from object header

Roman Kennke rkennke at openjdk.java.net
Thu Sep 16 17:01:57 UTC 2021

On Thu, 16 Sep 2021 16:43:30 GMT, Dave Dice <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). 

> 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.



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

More information about the lilliput-dev mailing list