RFR(T) JDK-8214797: TestJmapCoreMetaspace.java timed out
Chris Plummer
chris.plummer at oracle.com
Tue Apr 28 20:57:22 UTC 2020
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
More information about the serviceability-dev
mailing list