On Mon, 8 Aug 2022 13:45:06 GMT, Roman Kennke <rken...@openjdk.org> wrote:
> The bar for acceptance for a brand new locking scheme with no fallback is > extremely high and needs a lot of bake time and broad performance > measurements, to watch for pathologies. That bar is lower if the scheme can > be reverted to the old code if needed; and even lower still if the scheme is > opt-in in the first place. For Java Object Monitors I made the new mechanism > opt-in so the same could be done here. Granted it is not a trivial effort to > do that, but I think a phased approach to transition to the new scheme is > essential. It could be implemented as an experimental feature initially. I fully agree that have to be careful, but I share Roman's viewpoint. If this work is something we want to happen and which is not in doubt in principle, then we also want the broadest possible test front. In my experience, opt-in coding is tested poorly. A runtime switch is fine as an emergency measure when you have customer problems, but then both standard and fallback code paths need to be very well tested. With something as ubiquitous as locking this would mean running almost the full test set with and without the new fast locking mechanism, and that is not feasible. Or even if it is, not practical: the cycles are better invested in hardening out the new locking mechanism. And arguably, we already have an opt-out mechanism in the form of UseHeavyMonitors. It's not ideal, but as Roman wrote, in most scenarios, this does not show any regression. So in a pinch, it could serve as a short-term solution if the new fast lock mechanism is broken. In my opinion, the best time for such an invasive change is the beginning of the development cycle for a non-LTS-release, like now. And we don't have to push the PR in a rush, we can cook it in its branch and review it very thoroughly. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/9680
