shenandoah-dev Digest, Vol 100, Issue 40

[Kirill A. Korinsky]

Hi Ramki,

On Fri, 19 Jan 2024 22:14:30 +0100,
Ramakrishna, Ramki wrote:
> 
> > Until I've figured out how to reproduce it, I have no idea how to trace it on
> > production environment without perofrmance degradation and it's clearly that
> > both -Xlog:safepoint=trace and -XX:+SafepointALot aren't an option here :(
> 
> Perhaps try `-XX:+SafepointTimeout` along with a suitably high value for the associated `-XX: SafepointTimeoutDelay=` value?
> 
> Here are their respective defaults:
> 
>   product(bool, SafepointTimeout, false,                                    \
>           "Time out and warn or fail after SafepointTimeoutDelay "          \
>           "milliseconds if failed to reach safepoint")                      \
>                                                                             \
> 
>   product(double, SafepointTimeoutDelay, 10000,                             \
>           "Delay in milliseconds for option SafepointTimeout; "             \
>           "supports sub-millisecond resolution with fractional values.")    \
>           range(0, max_jlongDouble LP64_ONLY(/MICROUNITS))                  \


I'm a bit lost here: how does it help in case of deadlock?

As far as I understand the vlaue should be high enough to not produce a lot of
logs, for example 500ms.

But, I don't understand how can it dump anything when the deadlock is had
happened, because all threads are blocked and simple wait.

From another hand I have better idea. Let call some function on that state via
GDB, print_safepoint_timeout() or something else?

-- 
wbr, Kirill