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

[Daniel D. Daugherty]

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