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

[Roman Kennke]

On Fri, 24 Mar 2023 02:49:11 GMT, David Holmes <dholmes 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

Well I would argue that the current implementation puts the lock record in the object header (in the form of a pointer into the stack, which is elsewhere used to identify which thread an object is locked by), and only displaces the object header onto the stack-frame, whereas the new implementation puts the lock record onto the lock-stack, which is still part of the JavaThread structure (and not heap-allocated ... although it used to be in an earlier incarnation). And it leaves the object header alone. So the correct name would be +UseStackLockRecord to turn on the new impl (where the old one would be called header lock record, or something like that). I like that name, but I suspect that it might be confusing because the old impl has traditionally been called 'stack-locking'.

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

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1486716156