On Thu, 1 May 2025 17:26:48 GMT, Joe Darcy <da...@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
