RFR: Pauses that do not affect heap occupancy should not report heap
Zhengyu Gu
zgu at redhat.com
Wed Oct 11 15:14:51 UTC 2017
Good to me too.
-Zhengyu
On 10/11/2017 08:11 AM, Roman Kennke wrote:
> Am 11.10.2017 um 13:38 schrieb Aleksey Shipilev:
>> http://cr.openjdk.java.net/~shade/shenandoah/stats-no-pause-heap/webrev.02/
>>
>>
>> We have done this before for Init Mark. After async region recycling,
>> Final Mark and Final Update
>> Refs are not freeing up the heap themselves. Ditto for Init and Final
>> Partial GC.
>>
>> Sample cycles:
>>
>> [19.879s][info][gc] GC(5) Pause Init Partial 2.188ms
>> [19.889s][info][gc] GC(5) Concurrent partial GC
>> 21740M->21828M(102400M) 10.035ms
>> [19.890s][info][gc] GC(5) Pause Final Partial 1.028ms
>> [19.894s][info][gc] GC(5) Concurrent cleanup 21828M->1312M(102400M)
>> 4.296ms
>>
>> ...and:
>>
>> [121.084s][info][gc] GC(9) Pause Init Mark 0.776ms
>> [121.317s][info][gc] GC(9) Concurrent marking 81944M->83220M(102400M)
>> 232.421ms
>> [121.320s][info][gc] GC(9) Concurrent precleaning
>> 83220M->83236M(102400M) 3.476ms
>> [121.356s][info][gc] GC(9) Pause Final Mark 35.520ms
>> [121.356s][info][gc] GC(9) Concurrent cleanup 83264M->21162M(102400M)
>> 0.305ms
>> [121.441s][info][gc] GC(9) Concurrent evacuation
>> 21162M->22165M(102400M) 84.215ms
>> [121.441s][info][gc] GC(9) Pause Init Update Refs 0.050ms
>> [121.698s][info][gc] GC(9) Concurrent update references
>> 22169M->23389M(102400M) 256.810ms
>> [121.699s][info][gc] GC(9) Pause Final Update Refs 0.522ms
>> [121.700s][info][gc] GC(9) Concurrent cleanup 23389M->4630M(102400M)
>> 0.859ms
>>
>> Testing: hotspot_gc_shenandoah
>>
>> Thanks,
>> -Aleksey
>>
> Ok looks good
>
More information about the shenandoah-dev
mailing list