[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR(T) JDK-8214797: TestJmapCoreMetaspace.java timed out
From:       Chris Plummer <chris.plummer () oracle ! com>
Date:       2020-04-30 4:01:33
Message-ID: 037e103e-6759-99c7-8294-050ef3a55ec4 () oracle ! com
[Download RAW message or body]

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
>>
>


[prev in list] [next in list] [prev in thread] [next in thread]