RFR(T) JDK-8214797: TestJmapCoreMetaspace.java timed out

[Daniel D. Daugherty]

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
>