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

List:       openjdk-hotspot-gc-dev
Subject:    Re: Request for Review (xs) : 8038928 - gc/g1/TestGCLogMessages.java fail with "[Evacuation Failure'
From:       Bengt Rutisson <bengt.rutisson () oracle ! com>
Date:       2014-05-07 8:34:57
Message-ID: 5369F031.3040903 () oracle ! com
[Download RAW message or body]


Hi Jon,

On 2014-05-07 05:01, Jon Masamitsu wrote:
> I now do not think there is a good enough way to save the
> part of test that tries to verify that no unexpected evacuation
> failure has occurred.   Making it meaningful and reliable
> eludes me so I'm simply deleting that part of  the test.
>
> http://cr.openjdk.java.net/~jmasa/8038928/webrev.01/
>
> Thank you to those that helped me get to this point and
> thank you to those that put up with my first attempt.

I'm not sure I understand why it is not possible to make the test stable 
by just setting the young gen size and heap size appropriately. But I 
don't have strong opinions about the test. Maybe just removing the check 
is the simplest solution.

It was Thomas who added the check for evacuation failure as part of this 
change:
http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/70a6a3c4cc3e

If Thomas is fine with just removing this check, I'm fine with it too. 
Thomas?

Thanks,
Bengt

>
> Jon
>
> On 4/28/2014 2:17 PM, Jon Masamitsu wrote:
>> The requirement that an evacuation failure not happen during this
>> test is based on the expected behavior of the GC and is not a
>> required behavior.  In some instance the evacuation failure will
>> happen, but it is a not a  GC failure if it does and is only an
>> unexpected path being followed.
>>
>> The test is not reliable but before removing it, I've made
>> some changes to try and save it.  I've modified the
>> test to slow down the allocations and changed the allocation to
>> allocate smaller objects (which also has a side effect of slowing
>> allocations).   The goal is to detect gross breakages of
>> evacuation failure while risking only very, very rare spurious
>> failures.
>>
>> I had reproduced the failure with the unmodified test and it
>> would fail within 30 minutes.  With the modifications, I haven't
>> seen the failure in a day of testing.
>>
>> If the modifications don't work, I'll remove the test.
>>
>> http://cr.openjdk.java.net/~jmasa/8038928/webrev.00/
>>
>> https://bugs.openjdk.java.net/browse/JDK-8038928
>>
>> Thanks.
>>
>> Jon
>

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