G1 young dominated by code root marking

[Simone Bordet]

Hi,

On Tue, Oct 8, 2013 at 8:55 AM, Thomas Schatzl
<thomas.schatzl at oracle.com> wrote:
> We are aware of code cache scanning taking up a significant time of the
> collection pause - that's why starting with b106 the code cache scanning
> has been moved into an extra phase and parallelized.
> Previously the issue should have been worse (i.e. serialized) - or does
> this problem only surfaced with the new build?
> (Previously you would get a very long "Ext root scan" phase)

I did not test jdk 8 prior b109, unfortunately.

> I am afraid that at the moment afaik there is nothing but to reduce code
> cache size (or increase the number of available processors to benefit
> from parallelization).
>
> To help us analyze possible alternative remedies (i.e. class unloading
> after a concurrent marking cycle), does this problem persist even after
> stale code has been cleaned out, e.g. full gc?
> (I think full gc cleans out old code)

A preliminary test done by triggering a full GC after detecting a long
"code root marking" like you suggested showed a small reduction in
those times, but they remain dominant and exceed the G1 max GC pause.
Perhaps at steady state the code cache does not change much so the
amount of work related to it remain the same despite full GCs.

I am guessing code root marking cannot be made concurrent ?
Or split, like old generation regions evacuation is split during mixed GCs ?

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