G1gc compaction algorithm

[Thomas Schatzl]

Hi,

On Wed, 2014-07-16 at 09:41 +0300, Martin Makundi wrote:
> 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.

4M I guess (it does not matter).
> 
> 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 want that probably:
https://bugs.openjdk.java.net/browse/JDK-8038487
> 
> > 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?
> 
At the end of GC it prints for what purpose the regions are used
currently per region. One region per line, so it fills up your logs.

However using it you can see if the humongous allocation request of a
particular size could actually fit or not. The described behavior fits
the typical symptoms for that issue.

Thanks,
Thomas