RFR(S): 8010780: G1: Eden occupancy/capacity output wrong after a full GC
Jon Masamitsu
jon.masamitsu at oracle.com
Mon Apr 8 22:16:09 UTC 2013
Changes look good.
Jon
On 04/08/13 11:56, John Cuthbertson wrote:
> Hi Everyone,
>
> Thomas Schatzl has reviewed these change (thanks Thomas!) so I'm
> looking for one additional reviewer. Any takers?
>
> Thanks,
>
> JohnC
>
> On 3/27/2013 3:12 PM, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have a couple of volunteers look review this fix? The webrev
>> can be found at: http://cr.openjdk.java.net/~johnc/8010780/webrev.0/
>>
>> Summary:
>> One of the performance team spotted and error in the G1 logs
>> following a full GC:
>>
>> 411.322: [G1Ergonomics (Mixed GCs) (to-space exhausted), 0.4279260
>> secs]
>> ....
>> [Eden: 0.0B(1840.0M)->0.0B(1840.0M) Survivors: 0.0B->0.0B Heap:
>> 36.0G(36.0G)->36.0G(36.0G)]
>> [Times: user=1.13 sys=0.10, real=0.43 secs]
>>
>> 411.336: [Full GC (Allocation Failure) 35G->18G(36G), 8.0471890 secs]
>> [Times: user=8.50 sys=0.01, real=8.05 secs]
>>
>> 433.639: [GC pause (G1 Evacuation Pause) (young) 433.640:
>> [G1Ergonomics (CSet Construction) start choosing CSet,
>> _pending_cards: 26203, predicted base time: 13.50 ms, remaining time:
>> 186.50 ms, target pause time: 200.00 ms]
>> 433.640: [G1Ergonomics (CSet Construction) add young regions to
>> CSet, eden: 148 regions, survivors: 0 regions, predicted young region
>> time: 164.22 ms]
>> 433.640: [G1Ergonomics (CSet Construction) finish choosing CSet,
>> eden: 148 regions, survivors: 0 regions, old: 0 regions, predicted
>> pause time: 177.72 ms, target pause time: 200.00 ms]
>>
>> 433.895: [G1Ergonomics (Concurrent Cycles) request concurrent cycle
>> initiation, reason: occupancy higher than threshold, occupancy:
>> 21458059264 bytes, allocation request: 0 bytes, threshold:
>> 17394617520 bytes (45.00 %), source: end of GC]
>> , 0.2552910 secs]
>> ....
>> [Eden: 2368.0M(1840.0M)->0.0B(1632.0M) Survivors: 0.0B->304.0M
>> Heap: 20.7G(36.0G)->20.2G(36.0G)]
>>
>> The heap transition line for the GC after the full GC was displaying
>> the eden capacity that was calculated by the GC preceding the full GC
>> rather than the eden capacity calculated at the end of the of the
>> full GC. As a result the reported eden occupancy is much larger than
>> the reported capacity.
>>
>> The main part of the fix is the moving of
>> G1CollectorPolicy::_prev_eden_capacity from
>> G1CollectorPolicy::print_detailed_heap_transition() to
>> G1CollectorPolicy::record_collection_pause_start(). The code that
>> records the heap state before the GC has been refactored into a
>> separate routine and is invoked at the start of both an incremental
>> and full GC.
>>
>> Additionally I added a more detailed heap transition message to the
>> full GC output:
>>
>>> 1.989: [Full GC (Allocation Failure) 256M->234M(256M), 2.3966795 secs]
>>> [Eden: 0.0B(12.0M)->0.0B(12.0M) Survivors: 0.0B->0.0B Heap:
>>> 256.0M(256.0M)->234.7M(256.0M)]
>>> [Times: user=3.00 sys=0.00, real=2.40 secs]
>>>
>>
>> for validation purposes.
>>
>> Testing:
>> GCOld with a small heap (128m) and +G1PrintHeapRegions
>>
>> Thanks,
>>
>> JohnC
>>
>
More information about the hotspot-gc-dev
mailing list