Why G1 doesn't cut it for our application

[Cornelius Riemenschneider]

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140409/c14f95f5/attachment-0001.html>