G1: "Other" time too long ?

Simone Bordet simone.bordet at gmail.com
Thu Dec 11 18:16:39 UTC 2014


Hi,

thanks for the quick reply.

On Thu, Dec 11, 2014 at 5:58 PM, Yu Zhang <yu.zhang at oracle.com> wrote:
> Simone,
>
> Do you have  -XX:+G1SummarizeRSetStats?

Yes.

>  I had seen Other does not add up
> with this statistics, especially when RSet is big.

Ok, thanks for confirming this.
Have you seen differences as big as mine ?

> Currently the default G1RSetRegionEntries is set according to region size.
> So with bigger region size, you have more G1RSetRegionEntries.  You might
> get more references between regions with smaller region size.  You might
> already tried this, you can use -XX:+G1SummarizeRSetStats
> -XX:G1SummarizeRSetStatsPeriod=<n> to see if you have coarsening.  If
> coarsening is high, the RS operations are more expensive.

I did not have G1SummarizeRSetStats for the case with region_size = 16
MiB, but I do have it for the case region_size = 2 MiB.
I can see coarsenings in the latter case, so I guess it will be more
so for the former case, but I'll verify it.
The coarsenings I see are in the order 400-500 with peaks in the
thousands and one big at 289509.

I see that the formula to calculate the region entries is:

table_size = base * (log(region_size / 1M) + 1)

so for a 16 MiB region size the region entries are 564.

I'll retry with a higher value to see if I get any benefit.

Thanks !

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz


More information about the hotspot-gc-use mailing list