RFR: 8271931: Make AbortVMOnVMOperationTimeout more resilient to OS scheduling

Albert Mingkun Yang ayang at openjdk.java.net
Thu Aug 5 10:48:30 UTC 2021


On Thu, 5 Aug 2021 10:26:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/runtime/vmThread.cpp line 428:
>> 
>>> 426:         fatal("%s VM operation took too long: completed in " JLONG_FORMAT " ms (timeout: " INTX_FORMAT " ms)",
>>> 427:               _cur_vm_operation->name(), delay, AbortVMOnVMOperationTimeoutDelay);
>>> 428:       }
>> 
>> This duplicates `VMOperationTimeoutTask::task` body. So I think this is better to be moved to a separate method, e.g. `VMOperationTimeoutTask::check_and_fail`, which we can then call from both `::task` and `::disarm`.
>
> After this, we would also not need any other changes here: it would allow to check that task is `NULL` all the same.

Note the fatal msg is different: on VM thread we know the VM-op has completed, but on TimeoutTask the VM-op status is unknown.

How about sth like this?


bool check_timeout(jlong& delay) {
  delay = nanos_to_millis(os::javaTimeNanos() - _arm_time);
  return delay > AbortVMOnVMOperationTimeoutDelay
}

void disarm() {
  Atomic::release_store_fence(&_armed, 0);
  
  jlong delay;
  if (check_timeout(delay)) {
    fatal("%s VM operation took too long: completed in " JLONG_FORMAT " ms (timeout: " INTX_FORMAT " ms)",
        _cur_vm_operation->name(), delay, AbortVMOnVMOperationTimeoutDelay);
  }
}

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

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


More information about the hotspot-runtime-dev mailing list