Why G1 doesn't cut it for our application

[Thomas Schatzl]

Hi Cornelius,

On Wed, 2014-04-09 at 13:56 +0200, Cornelius Riemenschneider wrote:
> Hello,
> 
> after recently switching to the latest java 7 (u51), I was eager to
> try out G1.
>
> I used mainly
> http://www.slideshare.net/MonicaBeckwith/garbage-first-garbage-collector-g1-gc-migration-to-expectations-and-advanced-tuning for tuning, but 
>
> I hit a roadblock which makes it impossile for us to use G1.
>
> Our allocation pattern includes sometimes huge objects, sometimes in
> the range of ~120MB, sometimes ~600MB, but I’ve seen about 1.2GB as
> well. This is obviously unfriendly to the GC.
>
> Our tuned CMS mostly handles this, but sometimes we hit problems, so
> we had high expectations for G1.
>
> G1, in our case, triggers FullGC way more often than CMS, even when
> the heap is mostly empty.
>
>[...]
>
> We have a total of 20G for the heap available, and try to allocate
> objects in the 120MB range.
>
> 9 GB of the heap are free, so these should fit in without problems,
> even in Eden is a lot of free space.
>
> Still, G1 gets us a FullGC here. This FullGC may be faster than a CMS
> FullGC, but these happen way too often to be tolerated, especially as
> this server is responsible for a web
> application with which users directly interact – 20 secs pause after
> clicking are simply not tolerable.
>
> Besides using CMS, or not doing large allocations (which is sometimes
> impossible, given that we deal with a lot of data),
>
> do you have oher ideas?
>
> Is it known that an allocation pattern with a lot of huge objects
> breaks G1?

Current releases with G1 all have problems with many large objects.

The only workaround at this time I can think of, for the case when these
large objects are rather short-lived, is to increase the frequency of
the concurrent marking (decreasing InitiatingHeapOccupancyPercent to a
value where marking is running more frequently) to reclaim them faster.

Beginning with 8u20 effort has been put in to decrease this problem in
particular for shorter-living large objects.

If the heap is relatively empty, as in your case, one change that sorts
the free region list (https://bugs.openjdk.java.net/browse/JDK-8036025)
tends to help a lot. This change has been pushed to the 8u20 repository
already, and there may be a Java Early Access download for it already.

We have been working on a variety on other improvements in that area
lately, like a method to reclaim short-living large objects at every GC
(https://bugs.openjdk.java.net/browse/JDK-8027959) , or in case of a
dense heap, allocating objects in "tail regions" of large objects
(https://bugs.openjdk.java.net/browse/JDK-8031381). 

There are some more ideas floating around.

> The above linked presentation suggests to increase the G1 region size
> when humongous allocation requests are encountered, so these
> allocation go in eden, but we can not increase the region  size beyond
> 32M, so this fix doesn’t work for us.

As mentioned, the only suggestion I can think of at this time is to
decrease the InitiatingHeapOccupancyPercent appropriately so that the
marking will more frequently try to reclaim these large objects, leading
to more space available.

hth,
  Thomas