RFR (S) 8213723 / 8213893 - More Monitor/mutex initialization management

[David Holmes]

Thanks Dan!

David

On 16/11/2018 1:22 am, Daniel D. Daugherty wrote:
> On 11/14/18 11:24 PM, David Holmes wrote:
>> webrev: http://cr.openjdk.java.net/~dholmes/8213723/webrev/
> 
> src/hotspot/os/aix/os_aix.cpp
> src/hotspot/os/bsd/os_bsd.cpp
> src/hotspot/os/linux/os_linux.cpp
> src/hotspot/os/solaris/os_solaris.cpp
> src/hotspot/os/windows/os_windows.cpp
>      No comments on the above files.
> 
> src/hotspot/share/runtime/mutex.cpp
>      No comments.
> 
> src/hotspot/share/runtime/mutexLocker.cpp
>      No comments.
> 
> src/hotspot/share/runtime/mutexLocker.hpp
>      No comments.
> 
> src/hotspot/share/runtime/os.cpp
>      No comments.
> 
> src/hotspot/share/runtime/os.hpp
>      No comments.
> 
> src/hotspot/share/services/memTracker.cpp
>      No comments.
> 
> src/hotspot/share/services/memTracker.hpp
>      No comments.
> 
> Thumbs up!
> 
> Dan
> 
> 
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8213723
>>
>> I found a bunch of mutex/monitor instances that are dynamically 
>> created and embedded in classes rather than being part of the global 
>> mutex table. This isn't necessarily a problem as long as they aren't 
>> created before the low-level mutex initialization code has executed. I 
>> added some debug code to verify no mutex/monitor is created before 
>> os::init_2() has executed (which is a constraint imposed by Solaris 
>> sync code being dependent on argument parsing).
>>
>> I found one mutex that was created too soon, and that was the 
>> NMTQuery_lock, so that is now moved to the global list in MutexLocker. 
>> It's only used with the NMT DCmd and so doesn't need to be created 
>> exceptionally early.
>>
>> Just a reminder we don't see any problems today because mutex/monitor 
>> construction is trivial and independent of everything else. But the 
>> mutex/monitor rewrite that is being worked on requires OS 
>> initialization of mutex related attributes.
>>
>> Also trivially fixed:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8213893
>>
>> which deletes the unused StringTable_lock.
>>
>> Thanks,
>> David
>