RFR: 8212107: VMThread issues and cleanup [v7]

[Claes Redestad]

On Fri, 25 Sep 2020 12:20:37 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> We simplify the vmThread by removing the queue and refactor the the main loop.
>> This solves the issues listed:
>> - It can create an extra safepoint directly after a safepoint.
>> - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do.
>> - The exposure of the vm operation is dangerous if it's a handshake.
>> - The code is a hornets nest with the repetition of checks and branches
>> 
>> Passes t1-8, and a benchmark run.
>> 
>> If you want a smaller diff the commits contains the incremental progress and each commit passed t1.
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since
> the last revision:
>  - Merge branch 'master' into 8212107-vmthread
>  - Spelling fixes from Dan
>  - Removed assert as suggested by David
>  - Whitespace fixes, thanks to Shipilev
>  - Update after Shipilev
>  - Update after Coleen and David
>  - Merge branch 'master' into 8212107-vmthread
>  - Fixed nits
>  - Merge branch 'master' into 8212107-vmthread
>  - Fixes after review from shipilev.
>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/5d592be8...371ac282

src/hotspot/share/runtime/mutexLocker.hpp line 62:

> 60: extern Mutex*   RetData_lock;                    // a lock on installation of RetData inside method data
> 61: extern Monitor* VMOperation_lock;                // a lock on queue of vm_operations waiting to execute
> 62: extern Monitor* VMOperationRequest_lock;         // a lock on Threads waiting for a vm_operation to terminate

Can the declaration of VMOperationRequest_lock be removed now too? Since it's no longer being defined in mutexLocker.cpp

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

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