RFR: 8212107: VMThread issues and cleanup [v2]

[Robbin Ehn]

On Tue, 22 Sep 2020 20:46:33 GMT, Coleen Phillimore <coleenp 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/359def09...e49178a4
>
> src/hotspot/share/runtime/vmThread.cpp line 52:
> 
>> 50: #include "utilities/events.hpp"
>> 51: #include "utilities/vmError.hpp"
>> 52: #include "utilities/xmlstream.hpp"
> 
> Since you've changed a lot of the body of this, can you make sure that all these header files are needed?  method.hpp,
> runtimeService.hpp and dtrace.hpp may no longer be needed.  Check with precompiled headers off though.

Fixed

> src/hotspot/share/runtime/vmThread.cpp line 351:
> 
>> 349:     if (VMThread::vm_thread()->set_next_operation(op)) {
>> 350:       ml.notify_all();
>> 351:       break;
> 
> I was wondering if you should put some counter while the thread is waiting to install its operation for logging and
> debugging purposes?  Since the supposition is that there are few operations that cause safepoints so there's never a
> long wait.

Sounds like a good idea, fixing.

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

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