Request for Review (xs) : 8038928 - gc/g1/ fail with "[Evacuation Failure' found"

Bengt Rutisson bengt.rutisson at
Wed May 7 08:34:57 UTC 2014

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

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


> 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.
>> Thanks.
>> Jon

More information about the hotspot-gc-dev mailing list