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