RFR 8235678: Remove unnecessary calls to Thread::current() in MutexLocker calls

[coleen.phillimore at oracle.com]

This looks really good!  Thanks Harold.

I wonder if we see any reduction in instructions in startup, since some 
similar change did.  Maybe we can get Claes to measure it. :)

Thanks,
Coleen

On 1/15/20 7:57 AM, Harold Seigel wrote:
> Hi,
>
> Please review this new webrev that also makes Thread* the first 
> argument to the relevant MutexLocker and MonitorLocker constructors as 
> requested by Coleen.
>
> Updated Webrev: 
> http://cr.openjdk.java.net/~hseigel/bug_8235678.2/webrev/index.html
>
> Thanks, Harold
>
> On 1/14/2020 11:24 AM, coleen.phillimore at oracle.com wrote:
>>
>> Hi Harold,
>>
>> I really wanted this change to move Thread to the first argument like 
>> many of the other calls in the VM that take THREAD as an argument.
>>
>> Written like this:
>>
>> + MutexLocker mu(Threads_lock, THREAD);
>>
>>
>> It's too easy for someone who's cut/pasting to think the last THREAD 
>> argument should really be CHECK, which is completely wrong.
>>
>> Can you switch the arguments?
>>
>> Thanks,
>> Coleen
>>
>> On 1/14/20 9:00 AM, Harold Seigel wrote:
>>> Hi,
>>>
>>> Please review this small change, to reduce unnecessary calls to 
>>> Thread::current() in MutexLocker calls, by passing the current 
>>> thread as an argument.  A few ResoureMark declarations were also 
>>> changed.
>>>
>>> Open Webrev: 
>>> http://cr.openjdk.java.net/~hseigel/bug_8235678/webrev/index.html
>>>
>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8235678
>>>
>>> The fix was regression tested by running Mach5 tiers 1 and 2 tests 
>>> and builds on Linux-x64, Solaris, Windows, and Mac OS X, by running 
>>> Mach5 tiers 3-5 tests on Linux-x64, and JCK lang and VM tests on 
>>> Linux-x64.
>>>
>>> Thanks, Harold
>>>
>>