RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out (original) (raw)
Daniel Fuchs daniel.fuchs at oracle.com
Wed Jul 9 09:32:16 UTC 2014
- Previous message: RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out
- Next message: RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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/webrev8048913/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
- Previous message: RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out
- Next message: RFR: 8048913: java/util/logging/LoggingDeadlock2.java times out
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]