shenandoah-dev Digest, Vol 100, Issue 40

[Kemper, William]

Right, with Ramki's suggestion to use `-XX:+SafepointTimeout` it will log a warning with the status of only the threads that haven't reached the safepoint. There'd be no need to change the -Xlog configuration as I suggested earlier. Note, the default value for `XX:SafepointTimeoutDelay` is 10 seconds.


There is also a flag: `-XX:+AbortVMOnSafepointTimeout` that will terminate the JVM when a safepoint isn't reached before the timeout. This may be preferable to leaving the instance in an unresponsive state?


William

________________________________
From: Kirill A.Korinsky <kirill at korins.ky>
Sent: Friday, January 19, 2024 2:00:35 PM
To: Kemper, William
Cc: Ramakrishna, Ramki; shenandoah-dev at openjdk.org
Subject: RE: [EXTERNAL] shenandoah-dev Digest, Vol 100, Issue 40

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Fri, 19 Jan 2024 22:43:46 +0100,
Kemper, William wrote:
>
> It's not a true deadlock. The VMThread is in a busy loop checking if other
> threads have finished. The SafepointTimeout is checked during execution of the
> VMThread's busy/wait loop. See
> https://github.com/openjdk/jdk17u-dev/blob/master/src/hotspot/share/runtime/safepoint.cpp#L250.
>

Indeed.

That means I may use something huge like 1 second to avoid almost all logs
except when issue is happened, am I right?

--
wbr, Kirill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/shenandoah-dev/attachments/20240119/f57f860a/attachment.htm>