Biased locking Obsoletion

[Doerr, Martin]

Thanks for all your replies!

And thanks for bringing up JDK-8254078 again, Andrew!
I think we can live with the regression in jvm98, but we should better address the planned mitigations before finally removing BL.
Maybe there are more such kind of things planned?

Besides this, I'm only a bit concerned about the LTS users. I guess most "traditional" workload is running on jdk8 or 11.
So these users may notice the impact when migrating to 17. I hope people will not refrain from doing so because of missing BL.

Best regards,
Martin


> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Sonntag, 8. November 2020 23:05
> To: Doerr, Martin <martin.doerr at sap.com>; Patricio Chilano
> <patricio.chilano.mateo at oracle.com>; hotspot-runtime-
> dev at openjdk.java.net; hotspot-dev developers <hotspot-
> dev at openjdk.java.net>
> Subject: Re: Biased locking Obsoletion
> 
> Hi Martin,
> 
> On 7/11/2020 3:29 am, Doerr, Martin wrote:
> > Hi Patricio,
> >
> > seems like nobody wanted to be the first person to reply. So I just share a
> few thoughts.
> >
> > Unfortunately, I haven't heard any feedback from end users.
> > If the Biased Locking Code removal is not urgent because it's in the way for
> something else, I'd slightly prefer to remove it early in JDK17.
> >
> > My impression is that modern workloads are fine without BL, so typical
> JDK15 users will probably not notice it was switched off.
> >
> > Some old workloads are heavily affected, like SPEC jvm98. See
> performance drop on Power9:
> > http://cr.openjdk.java.net/~mdoerr/BiasedLocking_Power9.png
> > and on Intel Xeon E5:
> > http://cr.openjdk.java.net/~mdoerr/BiasedLocking_XeonE5.png
> >
> > Are there any plans for mitigations?
> 
> I don't see what mitigations are possible. We know that if you use
> heavily synchronized code when it is not necessary (i.e. uncontended)
> then BL shines at improving performance. Real "old" code would have been
> updated years ago to move away from the synchronized library classes
> (Vector, Hashtable) that typically result in these situations. Given
> that we can't update things like SPEC jvm98, they will show lower
> performance without BL. But I don't think we should care about this in 2020.
> 
> Cheers,
> David
> 
> > If so, it would be nice to implement them before finally removing BL.
> >
> > My 0.02$.
> >
> > Best regards,
> > Martin
> >
> >
> >> -----Original Message-----
> >> From: hotspot-runtime-dev <hotspot-runtime-dev-
> retn at openjdk.java.net>
> >> On Behalf Of David Holmes
> >> Sent: Dienstag, 3. November 2020 22:30
> >> To: Patricio Chilano <patricio.chilano.mateo at oracle.com>; hotspot-
> runtime-
> >> dev at openjdk.java.net; hotspot-dev developers <hotspot-
> >> dev at openjdk.java.net>
> >> Subject: Re: Biased locking Obsoletion
> >>
> >> Expanding to hotspot-dev.
> >>
> >>
> >> On 4/11/2020 7:08 am, Patricio Chilano wrote:
> >>> Hi all,
> >>>
> >>> As discussed in 8231264, the idea was to switch biased locking to false
> >>> by default and deprecate all related flags with the intent to remove the
> >>> code in a future release unless compelling evidence showed that the
> code
> >>> is worth maintaining.
> >>> I see there is only one issue that was filed since biased locking was
> >>> disabled by default (https://github.com/openjdk/jdk/pull/542) that
> seems
> >>> to have been addressed. As per 8231264 change, the code was set to be
> >>> obsoleted in 16, so we are already in a position to remove biased
> >>> locking code unless there are arguments for the contrary. The
> >>> alternative would be to give more time and move biased locking
> >>> obsoletion to a future release.
> >>> Let me know your thoughts.
> >>>
> >>> Thanks,
> >>>
> >>> Patricio