Odd G1GC behavior on 8u91
yu.zhang at oracle.com
yu.zhang at oracle.com
Thu Aug 25 17:17:41 UTC 2016
Vitaly,
Stefan.Karlsson points me to the right code. The current implementation
is when evacuation failure happens, the region that failed to evacuate
is turned into old region.
I still think it is confusing. In your logs, there is actually no young
regions(all are converted to old). But we are trying to do a young gc.
So 0 young regions in CSet.
We are still discussing this. But would like to give you an update.
I will take a look at your 2nd log.
Thanks
Jenny
On 08/25/2016 04:15 AM, Vitaly Davidovich wrote:
>
> The message after 'to-space exhausted' might be confusing. I need
> to discuss this with dev team. For example, at time stamp
> 2016-08-24T15:28:05.905+0000: 17709.633: [GC pause (G1 Evacuation
> Pause) (young)
> ...
> (to-space exhausted), 2.6149566 secs]
> ...
>
> [Eden: 28.4G(28.4G)->0.0B(28.4G) Survivors: 1664.0M->1664.0M Heap:
> 93.5G(96.0G)->73.9G(96.0G)]
>
> the eden used after gc might not be true. I will do some
> investigation and get back to you.
>
> Thanks. Yeah it's confusing. I'm still not sure I understand the log
> snippet I pasted in my initial email of the young evac immediately
> preceding the Full GC - it showed 0 regions in the CSet, so nothing
> was evacuated, but it also showed Eden occupancy of 0. It's then
> unclear why the Full GC triggers immediately after due to a 32 byte
> alloc request.
>
> Do you think that may be a bogus log as well?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20160825/241efe7e/attachment-0001.html>
More information about the hotspot-gc-use
mailing list