为什么在 G1GC 日志中有不同的堆使用描述

Question

我得到了 2 个关于堆使用的描述： occupancy: 21458059264 bytes和Heap: 15.5G(20.0G)->15.5G(20.0G) 。

第一个日志导致了一个完整的gc，但与第二个日志冲突，我很困惑。

JDK 是 OpenJDK_1.8.0

2020-01-02T00:32:06.965+0800: 222101.010: [GC pause (G1 Evacuation Pause) (young)
Desired survivor size 33554432 bytes, new threshold 3 (max 3)
- age   1:    9477752 bytes,    9477752 total
- age   2:    2296944 bytes,   11774696 total
- age   3:    1739960 bytes,   13514656 total
 222101.011: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 25370, predicted base time: 28.75 ms, remaining time: 61.25 ms, target pause time: 90.00 ms]
 222101.011: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 24 regions, survivors: 1 regions, predicted young region time: 7.03 ms]
 222101.011: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 24 regions, survivors: 1 regions, old: 0 regions, predicted pause time: 35.78 ms, target pause time: 90.00 ms]
 222101.019: [G1Ergonomics (Heap Sizing) attempt heap expansion, reason: region allocation request failed, allocation request: 51608 bytes]
 222101.019: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion amount: 51608 bytes, attempted expansion amount: 16777216 bytes]
 222101.019: [G1Ergonomics (Heap Sizing) did not expand the heap, reason: heap already fully expanded]
 222101.079: [G1Ergonomics (Concurrent Cycles) do not request concurrent cycle initiation, reason: still doing mixed collections, occupancy: 21458059264 bytes, allocation request: 0 bytes, threshold: 13958643660 bytes (65.00 %), source: end of GC]
 222101.079: [G1Ergonomics (Mixed GCs) do not start mixed GCs, reason: reclaimable percentage not over threshold, candidate old regions: 195 regions, reclaimable: 1940196760 bytes (9.03 %), threshold: 10.00 %]
 (to-space exhausted), 0.0691700 secs]
   [Parallel Time: 22.0 ms, GC Workers: 16]
      [GC Worker Start (ms): Min: 222101012.2, Avg: 222101012.3, Max: 222101012.4, Diff: 0.2]
      [Ext Root Scanning (ms): Min: 1.9, Avg: 2.2, Max: 4.3, Diff: 2.4, Sum: 34.9]
      [Update RS (ms): Min: 1.4, Avg: 3.7, Max: 5.0, Diff: 3.6, Sum: 59.0]
         [Processed Buffers: Min: 7, Avg: 19.1, Max: 35, Diff: 28, Sum: 306]
      [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 14.4, Avg: 15.6, Max: 15.9, Diff: 1.5, Sum: 250.3]
      [Termination (ms): Min: 0.0, Avg: 0.3, Max: 0.4, Diff: 0.4, Sum: 4.5]
         [Termination Attempts: Min: 1, Avg: 1.8, Max: 3, Diff: 2, Sum: 29]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.2]
      [GC Worker Total (ms): Min: 21.7, Avg: 21.8, Max: 21.9, Diff: 0.2, Sum: 349.0]
      [GC Worker End (ms): Min: 222101034.1, Avg: 222101034.1, Max: 222101034.2, Diff: 0.0]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.2 ms]
   [Other: 46.9 ms]
      [Evacuation Failure: 35.6 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 7.6 ms]
      [Ref Enq: 0.2 ms]
      [Redirty Cards: 0.2 ms]
      [Humongous Register: 1.5 ms]
      [Humongous Reclaim: 0.2 ms]
      [Free CSet: 0.0 ms]
   [Eden: 384.0M(384.0M)->0.0B(384.0M) Survivors: 16.0M->16.0M Heap: 15.5G(20.0G)->15.5G(20.0G)]
Heap after GC invocations=376428 (full 560):
 garbage-first heap   total 20971520K, used 16218220K [0x00000002c0000000, 0x00000002c1002800, 0x00000007c0000000)
  region size 16384K, 1 young (16384K), 1 survivors (16384K)
 Metaspace       used 59784K, capacity 60254K, committed 61056K, reserved 1103872K
  class space    used 6020K, capacity 6153K, committed 6272K, reserved 1048576K
}
 [Times: user=0.00 sys=0.00, real=0.07 secs]

Answer 1

我已经通过将 openJDK 升级到 8u232 解决了这个问题。

所以我怀疑这是 openJDK 8u202 的错误。