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
