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