Why G1 doesn't cut it for our application

[YU ZHANG]

Cornelius,

Humongous objects are treated specially in G1. They can only be cleaned 
after marking or full gc.

Usually we recommend to increase region size to avoid humongous 
allocation(It is humongous if the object size > half of the region 
size).  But it would not help in your case.  The max heap region size is 
32m.  As Thomas mentioned, there are some improvement in 8u20, and more 
improvements under investigation.

I am curious to know the performance after 8u20.  In addition to Thomas' 
suggestion, you can try to  reduce Eden size, and use 
-XX:+G1PrintRegionLivenessInfo  to print out region information after 
the marking phase.

Thanks,
Jenny

On 4/9/2014 4:56 AM, 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.
>
> 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

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