Request for Review (xs) : 8038928 - gc/g1/TestGCLogMessages.java fail with "[Evacuation Failure' found"
Bengt Rutisson
bengt.rutisson at oracle.com
Tue Apr 29 06:43:03 UTC 2014
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.
Thanks,
Bengt
>
> Thanks.
>
> Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140429/e3580ec5/attachment.htm>
More information about the hotspot-gc-dev
mailing list