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

[Daniel D. Daugherty]

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
>
>