RFR: 8271931: Make AbortVMOnVMOperationTimeout more resilient to OS scheduling

Albert Mingkun Yang ayang at openjdk.java.net
Thu Aug 5 17:26:33 UTC 2021


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

>> 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);
>>   }
>> }
>
> Huh, I missed this difference. Yeah, that goes in the right direction. Can we just pass the `const char*` with the format string to checking method? So we don't do the out-parameter, and the code ends up being:
> 
> 
> bool maybe_fail_with(const char* fail_msg) {
>   jlong delay = nanos_to_millis(os::javaTimeNanos() - _arm_time);
>   if (delay > AbortVMOnVMOperationTimeoutDelay) {
>      fatal(fail_msg, delay, AbortVMOnVMOperationTimeoutDelay);
>   }
> }
> 
> void disarm() {
>   Atomic::release_store_fence(&_armed, 0);
>   maybe_fail_with("VM operation took too long: completed in " JLONG_FORMAT " ms (timeout: " INTX_FORMAT " ms)");
> }

I actually think having the format string and the variables in the same scope/statement is better, because one can match the format specifier with the corresponding variable easily.

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

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


More information about the hotspot-runtime-dev mailing list