RFR: 8221360: Eliminate Shared_DirtyCardQ_lock

[Ivan Walulya]

On Sat, 14 Aug 2021 23:57:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the handling of a very rare race condition in
> concurrent refinement.  There is a situation where we many be unable to
> process a card and need to re-dirty and re-enqueue it for later processing.
> 
> The old code handled this using a shared dirty card queue, which various
> other places needed to know about as well.  This was the user of the
> Shared_DirtyCardQ_lock.  It was the only remaining Mutex whose rank is based
> on Mutex::access.
> 
> An option for eliminating that lock was to use a lock-free queue.  But
> rather than take on that complexity, we instead brute-force the problem.
> The new implementation simply allocates and enqueues an entire buffer for
> the one card that needs to be reprocessed.  Those operations are already
> lock-free.  The extra cost doesn't really matter, since this situation
> almost never arises.
> 
> This is now done inline in refine_card_concurrently.  It's not worth the
> overhead of a class for what is now just a few lines of code needed in
> exactly one place.  Places that knew about the shared queue in order to
> flush/reset it at certain points no longer have such responsibilities.
> 
> This change also renders JDK-8214997 moot, since there aren't any 'access'
> locks.
> https://bugs.openjdk.java.net/browse/JDK-8214997
> Crash holding 'access' lock can deadlock in JVMCI compiler thread
> 
> This change also allows the removal of Mutex::access.  That's being left to
> a new enhancement, since I think it also allows removing Mutex::tty,
> reverting back to using Mutex::event for the tty_lock.  That is, essentially
> undo JDK-8214315.
> https://bugs.openjdk.java.net/browse/JDK-8272480
> 
> Testing:
> mach5 tier1-5

Marked as reviewed by iwalulya (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/5118