Biased locking Obsoletion
Volker Simonis
volker.simonis at gmail.com
Mon Nov 9 11:30:54 UTC 2020
The following is just my personal opinion based on my feeling - it's
not backed by any data.
The arguments for removing BiasedLocking go like this:
- only single-threaded legacy code using legacy APIs is benefiting
from BiasedLocking
- badly written code (which can easily be fixed) is benefiting from
BiasedLocking
BiasedLocking was disabled in JDK15. That's not a release which is
widely used in production. Not many enterprise workloads have even
migrated to JDK 11. We know that migration to JDK 11 is hard and
migration to the next LTS version 17 will be even harder. Big
applications tend to have a lot of dependencies and code which can't
be easily upgraded or rewritten (even if it's badly written or uses
"old" APIs). In order to not introduce yet another upgrade problem I
think it would make sense to keep BiasedLocking alive in the next LTS
release 17. Removing it in 18 would be fine.
Best regards,
Volker
On Mon, Nov 9, 2020 at 11:19 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 09/11/2020 09:44, Andrew Haley wrote:
> > :
> > JDK-8254078 is a simple example, and a very modest proposal for change,
> > and it's still stuck in CSR.
>
> The CSR was approved and closed on Oct 24 so you should be good to go.
>
> -Alan
More information about the hotspot-dev
mailing list