On Tue, 9 Aug 2022 09:32:47 GMT, Roman Kennke <rken...@openjdk.org> wrote:
> I am not aware, please refresh my memory if you know different, of any core > hotspot subsystem just being replaced in one fell swoop in one single > release. Yes this needs a lot of testing but customers are not beta-testers. > If this goes into a release on by default then there must be a way for > customers to turn it off. UseHeavyMonitors is not a fallback as it is not for > production use itself. So the new code has to co-exist along-side the old > code as we make a transition across 2-3 releases. And yes that means a > double-up on some testing as we already do for many things. Maybe it's worth to step back a little and discuss whether or not we actually want stack-locking (or a replacement) *at all*. My measurements seem to indicate that a majority of modern workloads (i.e. properly synchronized, not using legacy collections) actually benefit from running without stack-locking (or the fast-locking replacement). The workloads that suffer seem to be only such workloads which make heavy use of always-synchronized collections, code that we'd nowadays probably not consider 'idiomatic Java' anymore. This means that support for faster legacy code costs modern Java code actual performance points. Do we really want this? It may be wiser overall to simply drop stack-locking without replacement, and go and fix the identified locations where using of legacy collections affects performance negatively in the JDK (I found a few places in XML/XSLT code, for example). I am currently re-running my benchmarks to show this. ------------- PR: https://git.openjdk.org/jdk/pull/9680
