RFR: 8212107: VMThread issues and cleanup

[Robbin Ehn]

On Fri, 18 Sep 2020 05:27:01 GMT, Aleksey Shipilev <shade 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.
>
> src/hotspot/share/runtime/vmThread.cpp line 355:
> 
>> 353:     }
>> 354:     ml.notify_all();
>> 355:     ml.wait();
> 
> It is really odd to see back-to-back `notify_all` and `wait`. Would that mean two threads sitting in this loop would
> just wake one another continuously?

This can theoretically be an issue if there is operation set and then two non-JavaThread trying set a operation.
Or if there is a handshake operation set.

I did not consider this scenario proper.
I think we need two separate Monitors.
Fixing

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

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