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

[Jon Masamitsu]

On 04/28/2014 11:43 PM, Bengt Rutisson wrote:
>
> Hi Jon,
>
> On 4/28/14 11: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
>
> Slowing down the test does not seem like a stable solution. Just like 
> you point out.
>
> What do you think about this instead?
>
> The original code does:
>
> // create 128MB of garbage. This should result in at least one GC
> for (int i = 0; i < 1024; i++) {
>   garbage = new byte[128 * 1024];
> }
>
> We run with -Xmx10M but no -Xmn set. We should only ever promote one 
> object each GC, so I assume that what happens when we get an 
> evacuation failure is that we get too many GCs that it fills up the 
> old space.
>
> How about specifying -Xmn and only allocate enough to fill the young 
> gen a few times. Instead of allocating 128MB we could maybe run with 
> -Xmn2M and allocate 8MB worth of objects. That should be enough to get 
> a few GCs but not enough to fill the old gen up. If you want to be 
> really safe you could also increase -Xmx to something like 128M.

The new code for GCTest is

     public static void main(String [] args) {
       System.out.println("Creating garbage");
       // create 128MB of garbage. This should result in at least one GC
       for (int i = 0; i < 1024; i++) {
         work(i);
         for (int k = 0; k < 1024; k++) {
           garbage = new byte[128];
         }
       }
       System.out.println("Done");
     }
   }

This still does as many young GC's but promotes less since object size
is only about 128 bytes.  I think that puts less pressure on the old gen
the way doing fewer GC's as you suggest.  I ran this test (without the
work method) for about half day without any failures and  then I
got an evacuation failure.  I looked at the heap and the old gen was
full.  I thought then that the allocation rate was just too high.  I
tried lowering the initiating occupancy but ran into another bug.
I then added the work() method and it's been running (product and
fastdebug) for a couple of days.

I could reshape the heap as you say and avoid the evacuation
failure but I don't know how much value that is.  Might be the
same as removing the requirement for no evacuation failure.
I settled on this because I thought I was close to an evacuation
failure (if something in the G1 changed like slower mixed collections
or concurrent marking cycle starting way too late, this might
caught it) but not too close (so that it happened very rarely
if it was just happenstance).

My first thought was just to remove the requirement that no
evacuation failure happened, but I vaguely felt it might be worth trying
to save.

Jon

>
> Thanks,
> Bengt
>
>>
>> Thanks.
>>
>> Jon
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140429/1a6b99f8/attachment.htm>