RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails intermittently in tier6 [v2]

[Daniel Fuchs]

On Thu, 1 May 2025 17:26:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Note, the timeout factor also adjusts the jtreg timeout for the entire test. The adjustTimeout() method allows internal test timeouts to scale along with the jtreg timeout.
>
>> Hi Joe, yes `adjustTimeout` will scale based on the jtreg timeout factor. I believe the behaviour is to multiply whatever hardcoded timeout is passed by the timeout factor. On lower tiers, in our CI, I beleive it means the test will have to wait for 8s before it can assert that a deadlock is detected. That should be way off the default jtreg timeout - which IIRC is 480s on lower tiers.
> 
> Catching up on PR comments, to make my concerns more explicit: it is best is we don't pessimize the common case of increasing the _minimum_ run time of the test in order to make the test more robust in highly-contended situations.

Right. But it's still way better than hard to diagnose intermittent failures. If this [the 2s x timeout factor minimum time] becomes an issue - I guess we could update the test to only test the case where there should no longer be a deadlock - and remove the self-test that proves that a deadlock would be detected if there was one.
That would need to be carried out in a different PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24687#discussion_r2070562152