On Mon, 24 Oct 2022 11:01:01 GMT, Robbin Ehn <r...@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
