[master] RFR: ObjectMonitor Storage

[Roman Kennke]

On Mon, 11 Apr 2022 15:42:56 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

> We worked very hard to get rid of TSM. I would cry a bit if this monster gets brought back from the dead. I also don't know if this compression is sound. I have seen SpecJBB2015 create millions of ObjectMonitors. So it doesn't sound too far fetched to assume that a larger app, for example one with a TB sized heap, would run out of address space for ObjectMonitors, even if only a reasonable percentage of objects need a monitor. I would very much prefer a solution that instead removes the ObjectMonitor pointer from the markWord completely, in favour of publishing the mapping with a (possibly optimized) hash table instead. Then you only need the hashCode in the markWord, TSM can stay dead, and it will scale better to large apps. Lookup time might be smaller, but that sounds like the better price to pay I think.

Hmm, yeah.
However, this is not as simple as it seems, that global lookup table needs to be MT safe. Probably something based on concurrentHashTable.hpp, at least for a first cut (probably structurally similar to what I did in #11 for GC forwarding). Do you have an particular optimizations in mind for the use-case?

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

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