AW: Why G1 doesn't cut it for our application

[Cornelius Riemenschneider]

Hello,
thanks for your answer. Unfortunately, building from source is not on the table for our production systems.
Will these changes only go in java 8, or will we see them in 7u60 or later versions of java 7?

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

-----Ursprüngliche Nachricht-----
Von: Jesper Wilhelmsson [mailto:jesper.wilhelmsson at oracle.com] 
Gesendet: Mittwoch, 9. April 2014 16:33
An: Cornelius Riemenschneider; hotspot-gc-use at openjdk.java.net
Betreff: Re: Why G1 doesn't cut it for our application

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-collect
> or-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
>