G1gc compaction algorithm

[Martin Makundi]

Hi!

I am not sure what's my issue, but according to logs the humongous object
size varies... usually it's the larger ones that hit the fan unless the
region size is too large to start with. I tried 16m and it seemed to make
itworse, tried couple more values here and there and 5M seems to work quite
nicely.

I suspect it's fragmentation issue, because most often Full GC occurs at
60-70% total heap used while the humongous object size is only 0,1% of the
total heap size.

So I suspect something like "continuous parallel compaction" could solve my
issue?

> You can get current region distribution information by eg. -XX:
> +PrintHeapAtGC -XX:+PrintHeapAtGCExtended .

First one I had already, will add latter one. What will these look like on
the logs, i.e., how can I search for them and look at the particular output?

**
Martin


2014-07-16 9:30 GMT+03:00 Thomas Schatzl <thomas.schatzl at oracle.com>:

> Hi Martin,
>
> On Wed, 2014-07-16 at 06:45 +0300, Martin Makundi wrote:
> > Hi!
> >
> >
> > Humongous allocation fails when there is not enough contiguous free
> > space in memory.
> >
> >
> > How does g1gc compaction algorithm work, does it compact only within a
> > region or does it attempt to compact in a whole-heap-defragmentation
> > way? The latter would reduce the probability of "humongous allocation
> > failure". And if this is possible, is there a parameter/s that can be
> > changed to tune this?
>
> Full GC compaction algorithm works by compacting on a whole-heap basis
> ignoring humongous objects. Humongous objects are never moved at this
> time.
>
> There is a recently discovered bug with that that does not consider
> humongous objects freed in the same collection
> (https://bugs.openjdk.java.net/browse/JDK-8049332) but leaves that space
> empty. This may actually be an advantage if the humongous object size is
> regular.
>
> Minor GC only ever evacuates, no compaction. There is no consideration
> to free memory so that it is contiguous after GC at this point.
>
> There are some patches in 8u20 (maybe 8?) that reduce fragmentation by
> playing around with object distribution per type.
>
> If you have quite short-living humongous objects of a particular type,
> there is https://bugs.openjdk.java.net/browse/JDK-8027959 which will
> likely be in 8u40.
>
> There are no particular knobs to turn to impact compaction density at
> this time except indirectly via heap region size (G1HeapRegionSize).
>
> You can get current region distribution information by eg. -XX:
> +PrintHeapAtGC -XX:+PrintHeapAtGCExtended .
>
> Thanks,
>   Thomas
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140716/aa7bf42c/attachment.html>