RFR: 8271931: Make AbortVMOnVMOperationTimeout more resilient to OS scheduling [v4]

[David Holmes]

On Sat, 7 Aug 2021 10:12:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Perform VM-op timeout also on the VM thread. If a VM-op is stuck, the existing watcher-thread based machinery will kick in and detect it.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   disarm

Hi Albert,

I preferred earlier versions that didn't shove all this extra logic into the timeout task, but it isn't worth arguing over.

Thanks,
David

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

> 82:   // The two stores to `_armed` are counted in VM-op, but they should be
> 83:   // insignificant compared to the actual VM-op duration.
> 84:   jlong vm_op_duration = nanos_to_millis(os::javaTimeNanos() - _arm_time);

You could move this ahead of the store. And then you only need a small comment in arm().

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

> 87:   // VMOperationTimeoutTask might miss the arm-disarm window depending on
> 88:   // the scheduling.
> 89:   assert(Thread::current()->is_VM_thread(), "Check timeout on VM thread");

Seems unnecessary to assert this.

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

> 92:           _vm_op_name, vm_op_duration, AbortVMOnVMOperationTimeoutDelay);
> 93:   }
> 94:   _vm_op_name = nullptr;

Yes clearing this is good hygiene - no dangling pointers.

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

Marked as reviewed by dholmes (Reviewer).

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