RFR: 8271931: Make AbortVMOnVMOperationTimeout more resilient to OS scheduling

David Holmes dholmes at openjdk.java.net
Fri Aug 6 02:14:31 UTC 2021


On Thu, 5 Aug 2021 17:23:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> 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.

I have no concerns about "duplicate" related checks here - it just isn't worth overthinking/over-engineering this IMO.

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

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


More information about the hotspot-runtime-dev mailing list