[jdk11u-dev] RFR: 8213137: Remove static initialization of monitor/mutex instances

[Volker Simonis]

On Wed, 9 Jun 2021 19:48:52 GMT, Evgeny Astigeevich <github.com+42899633+eastig at openjdk.org> wrote:

> We are backporting JDK-8210832: Remove sneaky locking in class Monitor. It has a few dependencies. JDK-8213137: Remove static initialization of monitor/mutex instances is one of them.
> 
> The original patch from JDK-8213137 causes conflicts. The conflicts are because a patched file does not exist in jdk11u and git struggled to position changes. The original changes are not changed after resolution of the conflicts.
> 
> Testing: Amazon Linux 2, aarch64, tier1 and tier2. Amazon Linux 2, x86_64, tier1 and tier2.

In general looks good. I'm only not sure if dropping the changes for `CodeCacheUnloadingTask::_lock` is really the right thing to do?

As you mentioned, [JDK-8213137](https://bugs.openjdk.java.net/browse/JDK-8213137) completely removed `CodeCacheUnloadingTask::_lock` because it was unused after [JDK-8209189](https://bugs.openjdk.java.net/browse/JDK-8209189). I agree that we shouldn't downport  [JDK-8209189](https://bugs.openjdk.java.net/browse/JDK-8209189), but  [JDK-8209189](https://bugs.openjdk.java.net/browse/JDK-8209189) was done **after** [JDK-8209841: [REDO] Refactor G1ParallelCleaningTask into shared](https://bugs.openjdk.java.net/browse/JDK-8209841). In JDK 11 we still have the situation **before**  [JDK-8209841](https://bugs.openjdk.java.net/browse/JDK-8209841) which means that Shenandoah GC is still using `CodeCacheUnloadingTask::_lock` in `src/hotspot/share/gc/shenandoah/parallelCleaning.cpp`.

So I think it might be reasonable for JDK 11 to remove the static initialization of `CodeCacheUnloadingTask::_lock` in the same way this has been done for the other monitors and move it to the global set of mutexes/monitors managed by `MutexLocker`.

Also notice that there was a follow-up change for [JDK-8213137](https://bugs.openjdk.java.net/browse/JDK-8213137) (i.e. [JDK-8213723](https://bugs.openjdk.java.net/browse/JDK-8213723)) which moved the `MemTracker::_query_lock` to the global set of monitors as well. You might also need that as prerequisite for [JDK-8210832: Remove sneaky locking in class Monitor](https://bugs.openjdk.java.net/browse/JDK-8210832).

-------------

PR: https://git.openjdk.java.net/jdk11u-dev/pull/21