Spikes in G1

[Kirk Pepperdine]

Hi all,

This is this mysterious G1 behavior that I’ve briefly mentioned to Erik that I keep seeing over and over again. I’ve just seen it again and this time I managed to get enough context to come with a hypothesis of why this is happening.
For quite some time I’ve noted that the G1 has a tendency to get into a condition where collections start to fail and occupancy spikes to the point where the condition can only be resolved with a Full GC. The Full GC will typically recover all of the memory consumed by the spike (and then some). This is a a bit unexpected for if the data is referenced, which it appears to be as other (mixed) attempts to collect do fail., then the full gc should fail to collect and occupancy should remain high. In this case weak references appear to be in involved in the sequence of events that lead up to the Full GC. You can see in this case that the number of weak references process do spike during the full. I need to go back and review other logs to see if this is the same for past occurrences.

I’m curious to understand if there is some unintended interplay between G1GC and WeakReferences that is ultimately responsible for heap occupancy to suddenly spike only to be completely reclaimed by a Full (even though mixed collections are running prior to the full).

Kind regards
Kirk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gc.log.20170709.150502.zip
Type: application/zip
Size: 4957843 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170711/9cba5b20/gc.log.20170709.150502.zip>