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

[Joe Darcy]

On Thu, 24 Apr 2025 16:24:53 GMT, Stuart Marks <smarks at openjdk.org> wrote:

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

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

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