G1: "Other" time too long ?

[Yu Zhang]

Simone,

Do you have  -XX:+G1SummarizeRSetStats?  I had seen Other does not add 
up with this statistics, especially when RSet is big.

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.

Thanks,
Jenny

On 12/11/2014 7:38 AM, Simone Bordet wrote:
> Hi,
>
> G1 with a 32 GiB heap (16 MiB region size), I was seeing high "Update
> RS" and "Scan RS" times during mixed GCs.
>
> I am aware of -XX:G1RSetRegionEntries, but I wanted to try another
> path: whether reducing manually the region size caused less inter
> region references and therefore reduced the probable coarsening that
> was the cause of the long RS times.
>
> So I set the region size to 2 MiB and re-run.
>
> Now I get very high "Other" times, for example:
>
>   [Other: 464.1 ms]
>        [Choose CSet: 0.1 ms]
>        [Ref Proc: 52.4 ms]
>        [Ref Enq: 1.8 ms]
>        [Redirty Cards: 19.4 ms]
>        [Free CSet: 22.7 ms]
>
> The sum of the subtask times is not close to the "Other" time so I was
> wondering what else it's done in the "Other" processing, or whether
> perhaps it is not reporting what I think (e.g. a sequential time vs a
> parallel time).
>
> I'd probably revert to a 16 MiB region size and setting
> G1RSetRegionEntries, but I was wondering if someone can shed some
> light on this.
>
> Logs are too big for this mailing list, but I can provide them to
> interested people.
>
> Thanks !
>