RFR: 8306774: Make runtime/Monitor/GuaranteedAsyncDeflationIntervalTest.java more reliable [v2]

[Aleksey Shipilev]

On Tue, 25 Apr 2023 20:38:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> > Previous version of this PR used the take-IHC-while-locked trick to inflate the monitors, but I figured it would not work after [JDK-8291555: Implement alternative fast-locking scheme](https://bugs.openjdk.org/browse/JDK-8291555) is here, and would quite probably be even less reliable as Lilliput progresses towards off-side IHC table.
> 
> Hmmm... I don't remember seeing anything in JDK-8291555 that would break the take-IHC-while-locked trick. I use that trick in some of my monitor stress tests... It would be sad to see that go away...

Perhaps I was too cautious about this. I figured that the practical reason to inflate the stack-locked object when IHC is requested is to deal with various races about the IHC installation in the displaced header. And since JDK-8291555 changes the stack-locking to not replace the header fully (only changing a bit, AFAIU), then IHC installation becomes much easier. But after reading the description again, I think JDK-8291555 only takes care of IHC on fastpath, i.e. when it is already installed. So take-IHC-while-locked might still work.

Still, I don't feel quite safe with relying on it, because it seems (famous last words) an easy future change to allow IHC installation into stack-locked object header after JDK-8291555, and I think there is a tentative plan to move IHC out of the header completely with 32-bit headers, which would make inflation even less of the practical behavior. So I believe `wait(1)` remains the only future-proof way to inflate the monitors, before we start to mess with JVM settings.

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

PR Comment: https://git.openjdk.org/jdk/pull/13634#issuecomment-1522956205