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

[Andrew Dinn]

Hi Daniel,

TL;DR Aargh, loom!

Otherwise see inline comments.

On 22/11/2019 15:06, Daniel D. Daugherty wrote:
> 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:

That's a fair point with the one proviso that /I/ didn't actually do any
of the editing . . .

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

Thank you for the careful exegesis. A-and, no! Of course I'm not trying
to be intentionally confrontational. I merely made the mistake of
responding to David's somewhat elliptical reduction of your original words.

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

Well, it seems I missed the ellipsis in David's statement -- where 'we'
was used in place of your original 'we (Oracle)'. Reading his statement
without awareness that several notes back 'we' was so qualified makes it
look as if he is committing the error of /petitio principii/ to bypass
the critique made in those intervening notes.

However, even granted the qualifier your textual spadework has restored
I still can't see how his use of 'we (Oracle)' justifies the notion that
'we (OpenJDK project)' should go ahead and removing biased locking
without (to quote the Martin Doerr, the person he was replying to)
'publishing an evaluation or at least having a discussion'. David didn't
actually answer that point, he merely reiterated the far less
contentious claim that switching it off without deprecation would be bad.

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

Of course, I agree that a silent change would not be good enough. The
issue still stands that little or no real evidence has (strictly, had --
see below) been presented for any change, /silent or not/. The only
clear reason offered at the point where I replied was the failure of
biased locking to improve performance in a specific benchmark. However
as Aleksey (one of the benchmark's developers) pointed out that
benchmark was designed explicitly to test cases where biased locking
would not help. I don't know what your eyesight is like but surely you
too need to squint to see that as sufficient?

>>> 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".
Well, as Marlon Brando said: What have you got?

It's hardly appropriate to ask /me/ to specify in advance what reason
/you/ need to give. Contrariwise, a request for /you/ to provide the
reason may be rather boringly conventional but it is not exactly out of
place.

n.b. the small hand grenade spelled 'loom' that was lobbed by Erik
Osterlund into an adjacent note in this thread might be a good place to
start ;-). I'm more than happy to surrender biased locking in the face
of the nightmare problems that loom's fragmentation of the notion of
identity implies for an implementation.

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