----- Original Message ----- > From: "John R Rose" <jr...@openjdk.org> > To: hotspot-...@openjdk.org, serviceability-dev@openjdk.org, > shenandoah-...@openjdk.org > Sent: Thursday, October 27, 2022 10:41:44 PM > Subject: Re: RFR: 8291555: Replace stack-locking with fast-locking [v7]
> 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. Hi John, a certainly stupid question, i've some trouble to see how it can be implemented given that because of lock coarsening (+ may be OSR), the number of time a lock is held is different between the interpreted code and the compiled code. Rémi > > ------------- > > PR: https://git.openjdk.org/jdk/pull/10590
