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