RFR: 8291555: Replace stack-locking with fast-locking [v7]

[John R Rose]

On Mon, 24 Oct 2022 11:01:01 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Secondly, a question/suggestion: Many recursive cases do not interleave locks, meaning the recursive enter will happen with the lock/oop top of lock stack already. Why not peak at top lock/oop in lock-stack if the is current just push it again and the locking is done? (instead of inflating) (exit would need to check if this is the last one and then proper exit)

The CJM paper (Dice/Kogan 2021) mentions a "nesting" counter for this purpose.  I suspect that a real counter is overkill, and the "unary" representation Robbin mentions would be fine, especially if there were a point (when the per-thread stack gets too big) at which we go and inflate anyway.

The CJM paper suggests a full search of the per-thread array to detect the recursive condition, but again I like Robbin's idea of checking only the most recent lock record.

So the data structure for lock records (per thread) could consist of a series of distinct values [ A B C ] and each of the values could be repeated, but only adjacently:  [  A A A B C C ] for example.  And there could be a depth limit as well.  Any sequence of held locks not expressible within those limitations could go to inflation as a backup.

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

PR: https://git.openjdk.org/jdk/pull/10590