On Thu, 24 Apr 2025 16:24:53 GMT, Stuart Marks <sma...@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
