2013-10-24 23 views
8

我有gc日誌啓用-XX:+PrintTenuringDistribution。但我對下面的時間分配感到困惑。如何讀取+ PrintTenuringDistribution的輸出

從我讀到的情況來看,第一個gc中的年齡1(從1 GC中存活)中有10532656個字節。在第二個gc中,2歲的9178824字節(從2個GC中存活)。這很好,因爲一些對象在第一個和第二個GC之間死亡。

但是在第二個GC中,16101552個字節在3歲時,而在第一個GC中僅2歲時爲14082976個字節。我不明白爲什麼這個數字在增加。 n年齡段的所有字節是不是應該來自前一個GC的年齡n-1?或者我誤解了這些數字?

謝謝。

2013-10-19T19:46:30.244+0800: 169797.045: [GC2013-10-19T19:46:30.244+0800: 169797.045: [ParNew 
Desired survivor size 87359488 bytes, new threshold 4 (max 4) 
- age 1: 10532656 bytes, 10532656 total 
- age 2: 14082976 bytes, 24615632 total 
- age 3: 15155296 bytes, 39770928 total 
- age 4: 13938272 bytes, 53709200 total 
: 758515K->76697K(853376K), 0.0748620 secs] 4693076K->4021899K(6120832K), 0.0756370 secs] [Times: user=0.42 sys=0.00, real=0.07 secs] 
2013-10-19T19:47:10.909+0800: 169837.710: [GC2013-10-19T19:47:10.909+0800: 169837.711: [ParNew 
Desired survivor size 87359488 bytes, new threshold 4 (max 4) 
- age 1: 9167144 bytes, 9167144 total 
- age 2: 9178824 bytes, 18345968 total 
- age 3: 16101552 bytes, 34447520 total 
- age 4: 21369776 bytes, 55817296 total 
: 759449K->63442K(853376K), 0.0776450 secs] 4704651K->4020310K(6120832K), 0.0783500 secs] [Times: user=0.43 sys=0.00, real=0.07 secs] 

編輯:

這已被確認爲JVM本身的錯誤是由於聲稱該對象的競爭條件。

的詳細討論可以在這裏找到:

http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2013-October/001635.html

+0

什麼看起來很腥,我建議你在OpenJDK郵件列表中詢問[email protected] –

+0

謝謝阿列克謝。我收到了郵件列表的回覆。這實際上是jvm中的一個錯誤。 –

回答

2

您正在閱讀的日誌權,問題就出在tenuring門檻,你有4

The GC parameter 「-XX:MaxTenuringThreshold」 defines how many minor GC cycles 
an object can stay in the survivor spaces until it finally gets tenured to the 
old space. 
規定

因此,根據您所配置的持續時間閾值,您可以將內存中的字節從一次清理累積到下一次,因爲您可以針對多輪GC回收特定年齡的內存。

例如,如果您想查看您希望看到的特定行爲,請在0上設置閾值。 OpenJDK的郵件列表([email protected])上

-XX:MaxTenuringThreshold=0—Makes the full NewSize available to every NewGC cycle, 
and reduces the pause time by not evaluating tenured objects. Technically, 
this setting promotes all live objects to the older generation, rather 
than copying them 
+0

謝謝,但那不能回答我的問題。我的問題是不變的「年齡n的所有字節是否來自前一個GC的年齡n-1」是否成立。日誌說這不是,但很難解釋。 –

+0

對不起不是要對答案很清楚,字節擺脫年齡的門檻已經達到後才年齡。所以你可能有1MB坐在一個特定的年齡4G輪,然後進入'n + 1'時代。 –

+1

謝謝吉列爾莫。此老化表僅適用於ParNew GC(年輕一代)。一旦對象生存的基礎一輪ParNew的GC(複製到倖存者,不老根),其老化的計數增加一個。所以它總是應該移到年齡n + 1。現在確認這是jvm本身的一個bug。不管怎麼說,還是要謝謝你。 –

3

討論表明這種異常tenuring分佈報告什麼的線程每個年齡計數器undating之間的競爭條件的結果。

錯誤JDK-8027363已填寫。從錯誤

摘錄:

這裏的問題:在用於複製的目標對象爲生存空間或者到老根的代碼,多個線程可以比賽要求的對象。如果對象的年齡低於使用期限,或者老一代不是CMS,我們將首先複製對象,然後通過將轉發指針交換到副本來聲明對象。其他副本被丟棄,獲勝線程繼續。問題在於,所有線程都在進行復制,從而增加了年齡表。修正是隻有比賽獲勝者才能增加年齡表以避免多次增加。