G1 young dominated by code root marking
Thomas Schatzl
thomas.schatzl at oracle.com
Mon Oct 7 23:55:58 PDT 2013
Hi,
On Tue, 2013-10-08 at 02:17 +0200, Simone Bordet wrote:
> Hi,
>
> using JDK 8 b109 (see below for details), and I see that when a
> concurrent cycle is requested, the young pause is completely dominated
> by code root marking.
> Below a typical log entry where a total pause of 210 ms spent 155 ms
> in code root marking.
>
> Is this normal behaviour ?
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)
The references scanned are references from the code cache (not from the
collected regions) into the Java heap.
> Does it depend on the ReservedCodeCacheSize (below at 256 MiB) ?
So, yes, the time taken is somewhat proportional to the amount of code
cache.
> Any hint to speed this up ?
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)
I.e. could you try a "jcmd <pid> GC.run" when this issue occurs and
report back results?
Thanks,
Thomas
More information about the hotspot-gc-use
mailing list