Thanks Dan!
On 4/29/20 3:34 PM, Daniel D. Daugherty wrote:
Thumbs up. And I agree that this is a trivial change.
Dan
On 4/28/20 4:57 PM, Chris Plummer wrote:
Hello,
Please review the following trivial change:
diff --git
a/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java
b/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java
--- a/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java
+++ b/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2018, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All
rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -26,5 +26,5 @@
* @summary Test verifies that jhsdb jmap could generate heap dump
from core when metspace is full
* @requires vm.hasSA
* @library /test/lib
- * @run driver/timeout=240 TestJmapCore run metaspace
+ * @run driver/timeout=480 TestJmapCore run metaspace
*/
Sometimes on our macs a core dump takes much longer than usual. The
usual time is not much different than our other hosts, typically
taking 3-5 minutes. However some times it takes much longer. We've
seen them take up to 27 minutes. Once it approaches 18 minutes,
that's when you see test timeouts. Doubling the timeout gives us 32
minutes, which would at least have prevented any of the timeouts
we've seen so far.
BTW, limiting the timeout does not seem to limit how long the test
takes when one of these core dumps takes a long time. The test will
not complete (and then timeout) until the core dump is done. So this
change is not impacting how much time we spend on the test if we
encounter an even longer core dump that results in a timeout.
thanks,
Chris
