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

[Erik Österlund]

Hi everyone,

Not sure which email to reply to.
Anyway, I thought somebody ought to highlight that biased locking is essentially a blocker for loom. If we want to keep biased locking, it has to be fundamentally redesigned. I can’t see anyone else mentioned that in this thread, so there we go.

With that said (and it is unfortunate it has not been said yet), if people want to keep this thing, then said people peobably should consider how they imagine this working with fibers.

The fundamental problem is: thread as ID is useless as everything runs on all threads suddenly, and we essentially have to revoke everything even when run from the same fiber. There have been some thoughts about putting some fiber oop in there instead or something, but that would make all GCs vomit all over the place, and it doesnt have the special alignment requirements that fat threads currently conform to when biased locking is enabled.

So yeah, loom. There is that. That is what I wanted to add to this conversation.

Thanks,
/Erik

> On 16 Nov 2019, at 03:16, Patricio Chilano <patricio.chilano.mateo at oracle.com> wrote:
> 
> Hi all,
> 
> Could you review the following patch?
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8231264
> Webrev: http://cr.openjdk.java.net/~pchilanomate/8231264/v01/webrev
> 
> Biased locking will be disabled by default and all related flags will be deprecated. Performance gains seen when the feature was introduced in the VM are less clear today with modern Java code/processors. Detailed rationale behind the change is included on the description of the bug.
> 
> I modified test gtest/oops/test_markWord.cpp so that it still exercises other cases of markword printing.
> 
> Tested with mach5, tiers1-6 on all platforms (Linux, macOS, Windows and Solaris).
> 
> Thanks,
> Patricio
> 
>