RFR: 8212107: VMThread issues and cleanup [v5]

[David Holmes]

On Wed, 23 Sep 2020 15:48:21 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 incrementally with one additional commit since the last revision:
> 
>   Whitespace fixes, thanks to Shipilev

src/hotspot/share/runtime/vmThread.cpp line 471:

> 469:   SafepointSynchronize::init(_vm_thread);
> 470:
> 471:   assert(Thread::current()->is_VM_thread(), "Must be the VM thread");

This is unnecessary, we don't need to guard against accidental calls to VMThread::loop by other threads!

src/hotspot/share/runtime/vmThread.hpp line 108:

> 106:
> 107:   static VM_Operation::VMOp_Type vm_op_type()     {
> 108:     VM_Operation* op = vm_operation();

Why use vm_operation() instead of direct access to _cur_vm_operation? Elsewhere you made the reverse change.

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

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