RFR 8231264: Disable biased-locking and deprecate all flags related to biased-locking

Fri Nov 22 16:29:22 UTC 2019

Hi all,

the only feasible argument for considering biased locking removal I've read so far is the one from Erik.
(Thanks, Erik!)

This should have been on the table before proposing deprecation.

If the plan is to deprecate it and later obsolete it in the release in which project loom enters main line,
I guess we (SAP) could agree with it.
It would be really helpful to communicate such plans before proposing deprecation.

Best regards,
Martin 

> -----Original Message-----
> From: Daniel D. Daugherty <daniel.daugherty at oracle.com>
> Sent: Freitag, 22. November 2019 16:06
> To: Andrew Dinn <adinn at redhat.com>; David Holmes
> <david.holmes at oracle.com>; Doerr, Martin <martin.doerr at sap.com>;
> Patricio Chilano <patricio.chilano.mateo at oracle.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: RFR 8231264: Disable biased-locking and deprecate all flags
> related to biased-locking
> 
> On 11/22/19 5:14 AM, Andrew Dinn wrote:
> > On 21/11/2019 21:31, David Holmes wrote:
> >> On 20/11/2019 2:51 am, Doerr, Martin wrote:
> >>> I think deprecating before publishing an evaluation or at least having
> >>> a discussion is not appropriate.
> >> Deprecation shows the intent that we (eventually) want to remove this
> >> and that people should try to avoid using it. If we don't actually
> >> deprecate it but just turn off then here is a likely scenario:
> > Who is this we?
> 
> The way you edited the original thread makes it look like the "we" comes
> out of no where. Okay. Not sure why you did that, but here's the complete
> context:
> 
> I posted this comment:
> 
> On 11/18/19 6:06 PM, Daniel D. Daugherty wrote:
> > As for the whole "too soon to deprecate" discussion: Deprecation is not
> > making the code obsolete so this changeset is not taking anything away
> > other than changing the default of UseBiasedLocking from true to false.
> > There are things that have been deprecated since JDK8 and they still
> > have not yet been made obsolete.
> >
> > Deprecating biased locking is the proper way of saying that we (Oracle)
> > and/or others think that biased locking should/will go away in a future
> > release. Yes, there are locking experts outside of Oracle that have said
> > that biased locking should go away, but I haven't gotten permission to
> > quote the folks (yet)...
> >
> > Deprecation is not final. Features can be un-deprecated if some
> > relevant facts and/or info changes the previous conclusion.
> 
> Martin posted this reply to my comment:
> > On 11/19/19 11:51 AM, Doerr, Martin wrote:
> >> Hi Dan,
> >>
> >>> As for the whole "too soon to deprecate" discussion: Deprecation is not
> >>> making the code obsolete so this changeset is not taking anything away
> >>> other than changing the default of UseBiasedLocking from true to false.
> >>> There are things that have been deprecated since JDK8 and they still
> >>> have not yet been made obsolete.
> >> I think deprecating before publishing an evaluation or at least having a
> discussion is not appropriate.
> >>
> >>> Deprecating biased locking is the proper way of saying that we (Oracle)
> >>> and/or others think that biased locking should/will go away in a future
> >>> release. Yes, there are locking experts outside of Oracle that have said
> >>> that biased locking should go away, but I haven't gotten permission to
> >>> quote the folks (yet)...
> >> There should be consent on the direction of possibly removing it before
> communicating it the hard way.
> >> However, switching it off for evaluation sounds feasible to me.
> >> Seems like we have some homework, too.
> 
> And David posted a reply to Martin's comment:
> 
> > On 11/21/19 4:31 PM, David Holmes wrote:
> >> On 20/11/2019 2:51 am, Doerr, Martin wrote:
> >>> Hi Dan,
> >>>
> >>>> As for the whole "too soon to deprecate" discussion: Deprecation is
> >>>> not
> >>>> making the code obsolete so this changeset is not taking anything away
> >>>> other than changing the default of UseBiasedLocking from true to
> >>>> false.
> >>>> There are things that have been deprecated since JDK8 and they still
> >>>> have not yet been made obsolete.
> >>>
> >>> I think deprecating before publishing an evaluation or at least
> >>> having a discussion is not appropriate.
> >>
> >> Deprecation shows the intent that we (eventually) want to remove this
> >> and that people should try to avoid using it. If we don't actually
> >> deprecate it but just turn off then here is a likely scenario:
> >>
> >> - we turn of BL in 14
> >> - customer updates to 14 sees a performance issue, checks the release
> >> notes, sees BL is disabled and turns it back on.
> >> - customer continues on their merry way and feels no need to report
> >> back to OpenJDK that they need BL (even if we ask them to via release
> >> notes)
> >> - we get no feedback that BL is still useful and so we deprecate it
> >> in, say, 16
> >> - customer updates to 16 and gets the deprecation warning and then
> >> reports back that they need BL
> >>
> >> Alternatively we deprecate in 14 and customer lets us know straight
> >> away that it is still useful.
> 
> So now David's use of "we" should be more clear. I do have to point out
> that my use of "we (Oracle)" was present in both Martin's reply and in
> David's reply to Martin, but for some reason you chose to edit it out.
> This makes your pushing back on David's use of an unqualified "we"
> questionable. Are you trying to be intentionally confrontational?
> 
> 
> > The premise of your scenario has built in the conclusion
> > that some of /us/ are questioning and thereby excluded our critique from
> > any chance of qualifying the proposed action.
> 
> Hmmm... I don't see anyone excluding critiques here, but maybe I've missed
> something...
> 
> 
> > If the existence of such a consensus is not clear (and I suggest that
> > this thread makes that plain) and the evidence for arriving at such a
> > consensus is not compelling (ditto) and if the rest of the scenario will
> > likely play out as you suggest then that is a strong reason to
> > re-address the decision to switch the feature off, whether or not it is
> > deprecated at the same time.
> 
> I suspect that "compelling" is in the eye of the beholder.
> 
> Simply changing the default from true to false is pretty much a silent
> change in behavior even if we put out a release note. By deprecating at
> the same time, we'll have a visible diagnostic message if biased locking
> is enabled. That's much more likely to lead to feedback than a silent
> change in behavior.
> 
> 
> >> Alternatively we deprecate in 14 and customer lets us know straight away
> >> that it is still useful.
> > Alternatively, we come up with better evidence that it needs switching
> > off (and, possibly, deprecating).
> 
> I wonder what would be considered acceptable "better evidence".
> 
> Dan
> 
> >
> > regards,
> >
> >
> > Andrew Dinn
> > -----------
> > Senior Principal Software Engineer
> > Red Hat UK Ltd
> > Registered in England and Wales under Company Registration No. 03798903
> > Directors: Michael Cunningham, Michael ("Mike") O'Neill
> >
> >