亞馬遜 Corretto 8 的補丁程序列表

本節列出套用到 OpenJDK 的所有修補程式。我們也提供 OpenJDK 專案中的問題連結。

[C8-1] 當長時間執行的原生呼叫暫停 G1 GC 呼叫時，避免過早 OutOfMemoryException。

使用 G1 GC 的程式可能發生假性記憶體不足 (OOM) 例外狀況，即使 Java 堆積離填滿尚早。當等候長時間執行的原生呼叫的旋轉循環在僅兩回合後放棄，即會發生此情況。這個小型修補程式可讓此循環只等待所需時間。一般而言再幾回合即足夠。在最糟的情況下，完整 GC 最終將發生 (由於 JDK-8137099)，也會解決問題。此修補程式包含單元測試，需要超過兩個回合，且只有在修補程式就定位時才會成功。請參閱 JDK-8137099 的討論。

[C8-2] OpenJDK 10 的後連接埠，修正JDK-8177809：「File.AstModified () 失去毫秒 (始終以 000 結尾)」。

該修補程式會移除檔案上次修改的時間戳記回報方式中的不一致。它會標準化建置平台的行為和 Java 方法，讓使用者接收第二個層級的精確度。請參閱 JDK-8177809。

[C8-3] OpenJDK9 的後連接埠，修復 JDK-8150013，「帕爾新：修剪 n方法可清理列表」。

此修補程式針對平行和 CMS 廢棄項目收集器降低暫停延遲。GC「根掃描」會加速，透過最多三個訂單驗收透過降低冗餘的程式碼檢測。

[C8-4] OpenJDK 9 的後連接埠，修正 JDK-8047338：“javac 未正確篩選非成員方法以獲得函數描述項”。

當功能界面擲出擴展例外狀況的例外狀況時，這個修補程式會修正造成編譯時期錯誤的編譯器錯誤。

[C8-5] OpenJDK 10 的後連接埠，修正 JDK-8144185：“javac 產生不正確的 RuntimeInvisibleTypeAnnotations 長度屬性”。

這個問題造成在某些格式正確的輸入程式中 Findbugs、JaCoCo 和 Checker Framework 失敗。

[C8-6] 根據字串表格成長觸發 G1 中的字串表格清除。

這個修補程式會根據字串表格成長 (而非 Java 堆積用量)，觸發清除字串表格項目所需的「混合式」G1 集合。後者是獨立的量測，很少或甚至從不在某些應用程式中觸發。然後，字串表格可以不受限制成長，也就是原生記憶體漏洞。請參閱 JDK-8213198。

[C8-7] 從 OpenJDK 9 的後端口，修復JDK-8149442：「MonitorInUseLists 默認處於打開狀態，使空閒監控器耗時過長」。

此修補程式會將移除高執行緒密集型應用程式的效能瓶頸設為預設設定。啟用 MonitorInUseLists 可更有效率地壓縮可能使用的監控器，而非整體監控器。

[C8-8] 從 OpenJDK 11 的後台端口，修復JDK-8198794：「熱點崩潰在卡桑德拉 3.11.1 與 Libnuma 2.0.3」。

此修補程式可避免 Cassandra 3.11.1 在啟動時損毀。

[C8-9] 從 OpenJDK 11 的後台端口，修復日本大學 8195115：「G1 Old Gen MemoryPool 集合用法。使用的值不反映混合式 GC 結果」。

如果沒有此修補程式，不可能在使用 G1 GC 時透過 JMX 判斷堆積的完整程度。

[C8-10] 加速 Class.getSimpleName() 和 Class.getCanonicalName()。

記憶可大幅加速這些功能。此修補程式包含正確性單元測試。請參閱 JDK-8187123。

[C8-11] OpenJDK9 的 JDK-8068736 後連接埠，修正「避免同步 Executable/Field.declaredAnnotations」。

透過可避免執行緒同步的結果快取，提高 Executable/Field.declaredAnnotations() 效能。

[C8-12] OpenJDK 9 的後連接埠，修正JDK-8077605：「初始化靜態字段會導致 javac 中的無限遞歸」。

[C8-13] 固定 JDK-8130493：「javac 在註釋處理器中以無提示的方式忽略格式不正確的分類」。

javac 在註釋處理器中以無提示的方式抑制格式不正確的分類檔案，並傳回結束代碼 0。有了此修補程式，javac 會回報錯誤訊息，並傳回非零的結束代碼。

[C8-14] 改善 jmap 工具錯誤訊息。

當目標程序沒有回應時，更新錯誤訊息以建議額外的方法。請參閱 JDK-8213443。

[C8-15] 已修復 JDK-8185005 的問題：「提高線程式。獲取線程信息（長 id []，整型 maxDepth）的性能」。

這個修補程式會提升 JVM 內部函數的效能，該函數會從作業系統執行個體執行緒 ID 查詢 Java Thread 執行個體。這會讓多個 ThreadMXBean 呼叫受益，例如 getThreadInfo()、getThreadCpuTime() 和 getThreadUserTime()。相對效能的改進會隨著 JVM 中的執行緒數量而提高，因為線性搜尋會由雜湊表格查詢所取代。

[C8-16] 來自 OpenJDK 12 的後台端口，修復日本大學-8206075：「在 x86 上，在未綁定彙編器標籤上宣告用作分支目標」。

標籤類別執行個體 (用於定義虛擬組件程式碼) 可能同時不正確地用於 C1 和解譯器。標籤最常見的錯誤是「分支到」，但從未透過 bind() 定義為程式碼的位置。新增宣告以擷取這些錯誤，並因此觸發 106 jtreg/熱點和 17 jtreg/jdk 測試故障。然後，我們會判斷當 UseLoopCounter 是 True，但 UseOnStackReplacement 是 False 時，標籤 backedge_counter_overflow 未繫結。目前透過上述測試已修正和保護。

[C8-17] 改善使用 gcc7 時 JVM 原始程式碼的可攜性。

此修補程式會在所有位置放置最新類型宣告，其中 gcc 切換 “-Wno-deprecated-declarations” 會標示問題。它還可讓切換擷取往後的相關問題。這可讓原始程式碼在所有現有 Amazon Linux 版本上編譯。這是多數 JDK-8152856、JDK-8184309、JDK-8185826、JDK-8185900、JDK-8187676、JDK-8196909、JDK-8196985、JDK-8199685、JDK-8200052、JDK-8200110、JDK-8209786、JDK-8210836、JDK-8211146、JDK-8211370、JDK-8211929、JDK-8213414 和 JDK-8213575 的組合。

[C8-18] JDK 10 的後連接埠，修正捷克-8195848：「JTREG 測試 StartManagementAgent 失敗」。

請參閱 http://serviceability-dev.openjdk.java.narkive.com/cDFwZce9 以取得詳細資訊。

[C8-19] 重新啟用傳統/停用的加密套件，以便通過兩個 TCK 測試 (否則會失敗)。

 

三個 OpenJDK9 提供的向後移植可支援使用預先安裝的程式庫。

後移植項目：JDK-8043805 適用於伊斯坦布爾、適用於公共交易所的 JDK-8035341，以及適用於中小型企業的 JDK-8042159。

整合 IcedTea 3.8 的 aarch64 支援。

 

更新供應商相關中繼資料。

指出 Amazon 是這個 OpenJDK 分發的供應商，並新增回報問題的連結。

來自 OpenJDK 9 的後端口，修復捷克-8048782：「OpenJDK：PiscesCache：xmax/ymax 四捨五入可能導致 RasterFormatException」。

此錯誤與接受 '(int minx,int miny,int maxx,int maxy)' 引數的 sun.java2d.pisces.PiscesCache 建構函式相關：內部 'bboxX1' 和 'bboxY1' 設定為大於 X 和 Y 指定上限值的值。