RFR: 8291555: Implement alternative fast-locking scheme [v29]

[David Holmes]

On Thu, 23 Mar 2023 16:32:57 GMT, Roman Kennke <rkennke at 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