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