Re: RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out
On 7/9/2014 2:32 AM, Daniel Fuchs wrote: On 7/9/14 5:46 AM, Mandy Chung wrote: Do you know if the test was run with -timeoutFactor? Or does it use the default timeout? Are you able to run the test with the same configuration (on same test machine) to see how long it takes? ... What I can see also is that on my machine (which is not slow), and a product build, the test (with jtreg) reports 0.484 secs of execution without -Xcomp and 8.075 with it - which makes a factor of 16.68 - but that's not counting the 'fastdebug' effect (and I'm not sure we can assume a linear scale anyway). ... With fastdebug + -Xcomp still on my machine it takes 41.931 secs. If the slowdown were linear it would need a timeoutFactor of ~ 86.63 ~42 secs and VM nightly may want to exclude this kind of tests. Thanks for the numbers. Your fix is good to go. Mandy
Re: RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out
On 7/9/14 5:46 AM, Mandy Chung wrote: On 7/8/2014 5:58 AM, Daniel Fuchs wrote: Hi, Please find below a fix for 8048913: java/util/logging/LoggingDeadlock2.java times out http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/ My suggestion is thus simply to remove the /timeout=15 from the @run command line, relying on the default jtreg timeout instead, which hopefully will have been tuned for the global configuration (fastdebug + -Xcomp) in which the testsuite is running. Do you know if the test was run with -timeoutFactor? Or does it use the default timeout? Are you able to run the test with the same configuration (on same test machine) to see how long it takes? I don't know. The machine that holds the log I had examined appears to be down. But I found another log on another machine where the test failed too - and I see it was called with -timeoutFactor=16.0 the test was killed after 240s, which looks like 16*15 if I'm not mistaken. What I can see also is that on my machine (which is not slow), and a product build, the test (with jtreg) reports 0.484 secs of execution without -Xcomp and 8.075 with it - which makes a factor of 16.68 - but that's not counting the 'fastdebug' effect (and I'm not sure we can assume a linear scale anyway). My own experience however tells me that attempting to specify timeouts directly in the test is a source of instability - and that leaving it up to jtreg is usually a better alternative. So I'd suggest trying to remove the timeout first and see how it goes. The fact that the test starts a subprocess doesn't help - as it makes it difficult to get debug information in case of timeout (but it's a deadlock test so we might not want to change the dynamics of the subprocess by adding too many debug traces). I'm not inclined to investigate too much as long as I can suspect the /timeout=15 parameter... -- daniel Mandy
Re: RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out
On 8/07/2014 10:58 PM, Daniel Fuchs wrote: Hi, Please find below a fix for 8048913: java/util/logging/LoggingDeadlock2.java times out http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/ jdk/test/java/util/logging/LoggingDeadlock2.java has been seen failing in timeout in some of our internal nightly builds. java/util/logging/LoggingDeadlock2.java StatusError Program `...' interrupted! (timed out?) As far as I could see this mostly happened with fastdebug builds, and the log I was able to examine showed that -Xcomp was also used. I believe that the issue here is that: 1. jdk/test/java/util/logging/LoggingDeadlock2.java starts a JVM subprocess 2. the @run command line defines /timeout=15 My suggestion is thus simply to remove the /timeout=15 from the @run command line, relying on the default jtreg timeout instead, Not unreasonable but how long does the test actually take to run on the problematic systems? which hopefully will have been tuned for the global configuration (fastdebug + -Xcomp) in which the testsuite is running. Hmm, well, no, not really. Xcomp + fastdebug + slow/small machines still leads to timeouts in places. We will just have to see how this one goes. David best regards, -- daniel
Re: RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out
On 7/8/2014 5:58 AM, Daniel Fuchs wrote: Hi, Please find below a fix for 8048913: java/util/logging/LoggingDeadlock2.java times out http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/ My suggestion is thus simply to remove the /timeout=15 from the @run command line, relying on the default jtreg timeout instead, which hopefully will have been tuned for the global configuration (fastdebug + -Xcomp) in which the testsuite is running. Do you know if the test was run with -timeoutFactor? Or does it use the default timeout? Are you able to run the test with the same configuration (on same test machine) to see how long it takes? Mandy
RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out
Hi, Please find below a fix for 8048913: java/util/logging/LoggingDeadlock2.java times out http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/ jdk/test/java/util/logging/LoggingDeadlock2.java has been seen failing in timeout in some of our internal nightly builds. java/util/logging/LoggingDeadlock2.java StatusError Program `...' interrupted! (timed out?) As far as I could see this mostly happened with fastdebug builds, and the log I was able to examine showed that -Xcomp was also used. I believe that the issue here is that: 1. jdk/test/java/util/logging/LoggingDeadlock2.java starts a JVM subprocess 2. the @run command line defines /timeout=15 My suggestion is thus simply to remove the /timeout=15 from the @run command line, relying on the default jtreg timeout instead, which hopefully will have been tuned for the global configuration (fastdebug + -Xcomp) in which the testsuite is running. best regards, -- daniel
