Why G1 doesn't cut it for our application

[Jesper Wilhelmsson]

Hi Cornelius,

G1 is known to have issues with very large objects, especially if they vary in 
size over the life of the application. If you have the option to build from 
sources (OpenJDK) you can try the latest version of G1. There have been some 
improvements to the large objects handling lately. Some of these changes could 
work in your favor.

Best regards,
/Jesper


Cornelius Riemenschneider skrev 9/4/14 13:56:
> 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.
>
> An example log excerpt for this:
>
> 399934.892: [G1Ergonomics (Heap Sizing) attempt heap expansion, reason:
> humongous allocation request failed, allocation request: 117245600 bytes]
>
> 399934.892: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion
> amount: 83886080 bytes, attempted expansion amount: 83886080 bytes]
>
> 399934.892: [G1Ergonomics (Heap Sizing) did not expand the heap, reason: heap
> expansion operation failed]
>
> 399934.893: [G1Ergonomics (Heap Sizing) attempt heap expansion, reason:
> humongous allocation request failed, allocation request: 117245600 bytes]
>
> 399934.893: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion
> amount: 83886080 bytes, attempted expansion amount: 83886080 bytes]
>
> 399934.893: [G1Ergonomics (Heap Sizing) did not expand the heap, reason: heap
> expansion operation failed]
>
> 399934.893: [G1Ergonomics (Heap Sizing) attempt heap expansion, reason:
> allocation request failed, allocation request: 117245600 bytes]
>
> 399934.893: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion
> amount: 117245600 bytes, attempted expansion amount: 117440512 bytes]
>
> 399934.893: [G1Ergonomics (Heap Sizing) did not expand the heap, reason: heap
> expansion operation failed]
>
> 2014-04-09T12:12:49.602+0200: 399934.894: [Full GC 11G->8118M(20G), 20.8752850 secs]
>
>     [Eden: 8192.0K(1016.0M)->0.0B(2728.0M) Survivors: 96.0M->0.0B Heap:
> 11.6G(20.0G)->8118.8M(20.0G)]
>
> [Times: user=37.77 sys=0.00, real=20.88 secs]
>
> 2014-04-09T12:13:10.479+0200: 399955.770: [GC concurrent-mark-abort]
>
> 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.
>
> The attempted heap expansion fails, because we use
>
> -Xms20g
>
> -Xmx20g
>
> which is the maximum the server is able to handle.
>
> 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?
>
> 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.
>
> Regards,
>
> Cornelius Riemenschneider
>
> --
>
> ITscope GmbH
>
> Ludwig-Erhard-Allee 20
>
> 76131 Karlsruhe
>
> Email: cornelius.riemenschneider at itscope.de
>
> https://www.itscope.com
>
> Handelsregister: AG Mannheim, HRB 232782
>
> Sitz der Gesellschaft: Karlsruhe
>
> Geschäftsführer: Alexander Münkel, Benjamin Mund, Stefan Reger
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>