On Thu, 23 Mar 2023 16:32:57 GMT, Roman Kennke <rken...@openjdk.org> wrote:
> Is anybody familiar with the academic literature on this topic? I am sure I > am not the first person which has come up with this form of locking. Maybe we > could use a name that refers to some academic paper? Well not to diminish this in any way but all you are doing is moving the lock-record from the stack frame (indexed from the markword) to a heap allocated side-table (indexed via the thread itself). The "fast-locking" is still the bit that use the markword to indicate the locked state, and that hasn't changed. Encoding lock state in an object header has a number of names in the literature, depending on whose scheme it was: IBM had ThinLocks; the Sun Research VM (EVM) had meta-locks; etc. Hotspot doesn't really have a name for its variation. And as I said you aren't changing that aspect but modifying what data structure is used to access the lock-records. So the property Jesper was looking for, IMO, may be something like `UseHeapLockRecords` - though that can unfortunately be parsed as using records for the HeapLock. :( I think it was mentioned somewhere above that in the Java Object Monitor prototyping work we avoided using these kinds of boolean flags by defining a single "policy" flag that could take on different values for different implementation schemes. These are simply numbered, so for example: - policy 0: use existing/legacy locking with stack-based lock records - policy 1: use heavyweight locks (ie UseHeavyMonitors) - policy 2 use the new approach with heap-allocated lock-records ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1482176363
