G1 feedback: adaptive size problems ?

[Simone Bordet]

Hi,

On Wed, May 2, 2012 at 9:14 AM, John Cuthbertson
<john.cuthbertson at oracle.com> wrote:
> Hi Simone,
>
> Thanks for trying out G1. I'll try and answer your questions.

Thank you for getting back to me.

> "to-space overflow" is what we call an evacuation failure or promotion
> failure. This happens when we run out of heap regions during the GC (for
> either/both survivors and promoted objects). As you can see this can be
> expensive. When an evacuation failure occurs, the GC still has to continue -
> we have a mixture of successfully and unsuccessfully copied objects and we
> have to fixup references to the objects that were successfully copied.
>  Objects that were not successfully copied are effectively tenured in place.
> Any updates to remembered sets of regions in the collection set (which we
> would ordinarily discard) have to be regenerated.
>
> As a result of the in-place tenuring, the old generation occupancy will
> increase (hopefully temporarily). Also if the evacuation failure occurs
> during marking - the in-place tenuring may make some regions look like bad
> candidates for collection during the following set of mixed GCs (it can look
> like they are fairly full of live data and hence expensive to collect).

Seems like a condition to avoid at all costs, since it's so expensive.

> There are a few things to try and stop the evacuation failure. The first is
> increase the heap size.

Right.
I doubled the sizes, and I could run the whole day with just young
GCs, but the target GC pause was mostly never respected, and I had
worst cases up to 500+ ms (target = 200 ms).
While I understand is a soft limit, it was mostly respected with a 1 GiB heap.

However, other algorithms (ParallelOld, CMS and JRockit's
deterministic, in particular the latter) do well with 1 GiB heap.
Perhaps I am pushing G1 to its low-end limit here, as I understand G1
targets larger heaps ?
But then why would the pauses be that longer for bigger heaps (also
given they were all young GC with a low survivor rate) ?

I had a suggestion to remove the -Xmn setting and leave G1 manage the
young generation, and I am trying that with a 1 GiB heap.

Thanks !

Simon
-- 
http://cometd.org
http://intalio.com
http://bordet.blogspot.com
----
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz