RFR: 8212107: VMThread issues and cleanup [v2]

[Robbin Ehn]

On Fri, 18 Sep 2020 21:38:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> 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 12 additional commits since
>> the last revision:
>>  - Merge branch 'master' into 8212107-vmthread
>>  - Fixed nits
>>  - Merge branch 'master' into 8212107-vmthread
>>  - Fixes after review from shipilev.
>>  - Fixed some indent misses
>>  - Fixed ws
>>  - Added assert
>>  - Restructured and simplified
>>  - Removed used linking in VM_Operation
>>  - Removed ticket and use only one Monitor
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/ecb5488e...e49178a4
>
> I probably should have waited to review this after all of Aleksey's
> comments were resolved. I'm gonna have to take a look at
> src/hotspot/share/runtime/vmThread.cpp again via a webrev;
> it's just too hard to review via this snippet UI.
> 
> I'll re-review after all of Aleksey's changes are done.

> Can you explain why it was necessary to remove the queue and exactly
> what it has been replaced with? I'd like to understand the new
> higher-level design for VMOperation execution rather than trying to
> reverse engineer it from the code changes.

VM operations now rare and when we do them they are now also faster compared to when the queue was introduced.
(I believe way back the VM thread did all compiles in no-safepoint op, safepoint was on the higher prio vs lower prio
non-safepoint ops) During a normal execution we do handshakes and safepoints. The handshakes we default do used to be
safepoint, there is no reason to threat them with a lower prio. We reach the safepoint much faster nowadays, which
means there is very little time to add anything to a queue. And to reach safepoint faster it would be better to stop
for the safepoint than adding anything to a queue before stopping.

So we replace the queue with a "next safepoint operation".
Any other safepoint requester will have their operation on their stack until they succeed to set it as "next safepoint
operation".

> 
> Thanks,
> David
> -----

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

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