Why G1 doesn't cut it for our application

[Thomas Schatzl]

hi,

On Thu, 2014-04-10 at 16:08 +0200, Cornelius Riemenschneider wrote:
> Hi,
> I finally tried 8u20 b5 (a precompiled early access build) on a test server.
> Triggering FullGCs with our not-so-allocation-heavy application by hand (without the load of our real users) is hard even with 7u51, so I didn't try that.
> On the other hand, load-testing our allocation-heavy software is very easy, and triggered loads of FullGCs with 7u51.
> 8u20 does way better with my current test.

That's great to hear :) Thanks for trying out the new build.

> I can't really interpret the output of PrintHeapAtGCExtended, so I've attached the (hopefully relevant) log from before and after the fullgc.

Let me try to explain the relevant information: every line in this log represents a region of the heap, from the bottom address to top address. Relevant for this problem are the columns on the left (up to but not including "TS"), and the percentage before "used".  So, what's important here are "HS", "HC" and "F" strings.

HS means that in that particular region a humongous objects starts, HC
regions are regions the object in the previous humongous start region
extend into.
"F" regions that are completely free for allocation.

So, any new humongous object needs a contiguous sequence of free regions
for allocation, so the GC is looking for long contiguous sequences of "F"
regions.

This seems to be the problem: longer sequences of free regions are often
broken up by single regions with content.

Another aspect is how much of the area occupied by large objects is actually taken up by the object: the "used" percentage for the "HS" region shows that for the entire object. E.g. something like 51% is really bad, while 90%+ is probably okay. From what I saw, in your case most objects are very large, so the used/total space percentage is typically good.

> Is this a problem which can be fixed with other gc settings on my end,

The only setting I can see that could affect something from the user end
would be increasing heap region size. Not the best option, but possibly
worth a try as it reduces the required number of consecutive free regions
(but then it also reduces the number of total available regions).

>or can you improve G1 further to target our allocation pattern?

Jdk8u20-b08 includes a set of further optimizations for G1, some that
should directly improve your use case. I do not know when/if it will be
available for download in the Java Early Access program.

Further improvements will be included with later releases only though,
i.e. 8u40/9. You could subscribe to notifications for the mentioned CRs
to at least get information about changes.

JDK-8038487 "G1: use mixed GC instead of Full GC to clear out space for
failing humoungous object allocations" is the one I did not remember
last time, and probably addresses the problem with your application
directly.

I added the log you sent to the CR as an example - thanks for discussing
your problem here.

Contributions are always welcome to make things happen faster though ;)

Thomas