IBM JRE gencon策略中的歧義和詳細信息：gc輸出

Question

我正在協助一個項目來調整他們的應用程序服務器環境，並且我看到來自IBM JRE的冗長的gc日志中的一些相當混亂的輸出，我比Hotspot更不熟悉。 在許多情況下，似乎與我在供應商的文檔中看到的內容相矛盾。 這適用於在IBM的1.7_64 JRE上運行的在Websphere上運行的應用程序。 這個特定的運行是使用gencon GC策略，堆大小為4GB。 以下是全局GC的詳細：gc輸出示例，它是眾多歧義的來源，我將在下面詳細介紹：

<exclusive-start id="8574" timestamp="2015-09-08T22:48:45.819" intervalms="2919.893">
    <response-info timems="0.229" idlems="0.069" threads="43" lastid="0000000005FF6800" lastname="WebContainer : 37" />
</exclusive-start>
<sys-start id="8575" timestamp="2015-09-08T22:48:45.820" intervalms="3028473.245" />
<cycle-start id="8576" type="global" contextid="0" timestamp="2015-09-08T22:48:45.820" intervalms="3028473.281" />
<gc-start id="8577" type="global" contextid="8576" timestamp="2015-09-08T22:48:45.820">
    <mem-info id="8578" free="462493104" total="4155310080" percent="11">
        <mem type="nursery" free="80236904" total="934084608" percent="8" />
        <mem type="tenure" free="382256200" total="3221225472" percent="11">
            <mem type="soa" free="221195336" total="3060164608" percent="7" />
            <mem type="loa" free="161060864" total="161060864" percent="100" />
        </mem>
        <remembered-set count="16780" />
    </mem-info>
</gc-start>
<allocation-stats totalBytes="745771152" >
    <allocated-bytes non-tlh="193377184" tlh="552393968" />
    <largest-consumer threadName="WebContainer : 49" threadId="000000000659E600" bytes="156075608" />
</allocation-stats>
<gc-op id="8579" type="mark" timems="609.025" contextid="8576" timestamp="2015-09-08T22:48:46.429">
    <trace-info objectcount="9486509" scancount="7257956" scanbytes="246533016" />
    <finalization candidates="1528" enqueued="411" />
    <ownableSynchronizers candidates="32" cleared="0" />
    <references type="soft" candidates="63260" cleared="0" enqueued="0" dynamicThreshold="30" maxThreshold="32" />
    <references type="weak" candidates="27120" cleared="11" enqueued="0" />
    <references type="phantom" candidates="17361" cleared="7885" enqueued="7885" />
    <stringconstants candidates="153217" cleared="105"    />
</gc-op>
<gc-op id="8580" type="classunload" timems="1.114" contextid="8576" timestamp="2015-09-08T22:48:46.430">
    <classunload-info classloadercandidates="4306" classloadersunloaded="26" classesunloaded="26" quiescems="0.000" setupms="0.955" scanms="0.108" postms="0.051" />
</gc-op>
<gc-op id="8581" type="sweep" timems="18.520" contextid="8576" timestamp="2015-09-08T22:48:46.449" />
<gc-op id="8582" type="compact" timems="2209.475" contextid="8576" timestamp="2015-09-08T22:48:48.658">
    <compact-info movecount="9482641" movebytes="539414400" reason="compact on aggressive collection" />
</gc-op>
<gc-end id="8583" type="global" contextid="8576" durationms="2839.085" timestamp="2015-09-08T22:48:48.659">
    <mem-info id="8584" free="3615704600" total="4155310080" percent="87">
        <mem type="nursery" free="834618336" total="934084608" percent="89" />
        <mem type="tenure" free="2781086264" total="3221225472" percent="86">
            <mem type="soa" free="2620025400" total="3060164608" percent="85" />
            <mem type="loa" free="161060864" total="161060864" percent="100" />
        </mem>
        <pending-finalizers system="367" default="44" reference="7885" classloader="0" />
        <remembered-set count="15785" />
    </mem-info>
</gc-end>
<cycle-end id="8585" type="global" contextid="8576" timestamp="2015-09-08T22:48:48.659" />
<sys-end id="8586" timestamp="2015-09-08T22:48:48.659" />
<exclusive-end id="8587" timestamp="2015-09-08T22:48:48.659" durationms="2839.704" />

問題包括：

1）GC操作的時間戳（標記為gc-op）似乎是在操作完成時，而不是從啟動時開始。 IBM doc暗示時間戳是該操作發生的時間（ http://www-01.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.zos.71.doc/diag/tools/gcpd_verbose_operation。 HTML ）。 但是，在查看操作的時間戳和持續時間（由timems屬性標識）時，數字不會相加。 但是，如果將時間戳解釋為操作完成時，而不是在操作開始時，它們會加起來並且有意義。 為了說明，在上面的示例輸出中執行了以下操作，這些是它們提供的持續時間和時間戳（我已經舍入了數字）：

operation - duration - timestamp
    mark - 609ms - 48:46.429
    classunload - 1ms - 48:46.430
    sweep - 19ms - 48:46.449
    compact - 2209ms - 48:48.658

可以看出，如果將時間戳解釋為開始時間，則時間戳沒有意義。 但是，如果將它們解釋為結束時間。 例如，classunload時間戳值等於makr時間戳加上cla​​ssunload持續時間（如果時間戳指示操作何時開始，則不應加上標記持續時間）。 同樣，掃描時間戳等於classunload時間戳加上掃描持續時間。

有人可以確認這是否是預期的行為，還是我只是錯誤地閱讀？

2）另一個問題似乎是日志中的每個操作都是從頭到尾的全程操作。 我預計清除GC將全部停止，但是，我從IBM看到的所有文檔都表明，全球GC的標記階段至少應該同時完成。 但是，這也不是上面GC日志條目中發生的情況。 在這個例子中，似乎一切都是作為一個句號完成的，並且標記的任何部分或者掃描都不是同時完成的。 每個（較舊的）文檔至少部分標記應該同時完成，而不是作為停止世界停頓的一部分（ http://www.ibm.com/developerworks/java/library/j-ibmjava2/ ）是否有一個設置可以使終身代的全球GC同時成為周期的一部分？ 我知道這是在IBM JREs optavgpause收集器以及Hotspot並發收集器中完成的，這兩者都不是特別新技術，因此不清楚為什么gencon每次必須做的時候總是強制完全停止世界全球收藏。 這很重要，因為上面指出的2.8秒暫停將使我們與客戶端的SLA發生沖突。

3）在上面的全球氣相色譜中，從苗圃的占用數量可以看出，在這次手術中它也被收集（苗圃在GC之前只有8％免費，之后只有89％）。 但是，我沒有看到關於輸出中托兒所中發生的GC的相關信息。 我希望看到這里記錄的scavange操作。 有誰知道為什么這個缺失？ 這是因為在全球GC期間，還通過相同的堆行走（標記 - 掃描 - 緊湊）方法收集托兒所，因為當全局GC發生時，終身空間是什么？

Answer 1

你是對的，因為你看到停止了由獨家開始和獨家終端覆蓋整個周期的世界收藏。 我覺得有趣的是，當堆甚至沒有完全分配時，你會看到一個全局gc。

我認為你有sys-start和sys-end條目的原因似乎表明你的應用程序（或遠程GC）中的某些東西正在觸發System.gc（），你應該首先解決這個問題並獲得一個新的一套gc日志。

Answer 2

注意到這個問題已經過時了，但是在Q1和Q3中添加答案以供參考。

1.您對時間戳正確。 請注意，gc-op標記實際上告訴您它在gc操作階段已經執行了什么。 這就是時間戳指示操作結束的原因。

3.在全球GC期間 - 進行任期和清除收集。 在全局采集期間，這些不會單獨記錄在GC日志中。