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