這篇文章著眼于轉(zhuǎn)義分析，特別是jvm在運(yùn)行的程序中執(zhí)行轉(zhuǎn)義分析需要多長(zhǎng)時(shí)間。 我做了一些觀察，但目前還沒有全部解釋。

作為介紹，讓我們繞道看看jvm -Xcomp中一個(gè)鮮為人知且使用更少的標(biāo)志（這將是一件好事）。

該標(biāo)志的行為在jvm 文檔中定義為：

-Xcomp在第一次調(diào)用時(shí)強(qiáng)制編譯方法。 默認(rèn)情況下，客戶端VM（ -client ）執(zhí)行1,000個(gè)解釋方法調(diào)用，服務(wù)器VM（ -server ）執(zhí)行10,000個(gè)解釋方法調(diào)用，以收集信息以進(jìn)行有效的編譯。 指定-Xcomp選項(xiàng)會(huì)禁用解釋的方法調(diào)用，從而以提高效率為代價(jià)來提高編譯性能。

乍一看，這似乎是一個(gè)極好的選擇。 在10,000個(gè)周期內(nèi)預(yù)熱jvm的快捷方式–我們可以直接編譯代碼。 我們是否應(yīng)該始終默認(rèn)啟用此選項(xiàng)？

但是文檔確實(shí)警告說，這將“以犧牲效率為代價(jià)”。

jvm在10,000個(gè)預(yù)熱周期中了解代碼行為，以便在編譯時(shí)以最有效的方式進(jìn)行編譯。 立即編譯代碼意味著可以，確實(shí)可以編譯代碼，但是編譯后的代碼可能不是最有效的。 您可以在此博文中閱讀有關(guān)它的更多信息-但這并不是本文的主題。

如果使用-Xcomp，則不會(huì)發(fā)生的其他事情是轉(zhuǎn)義分析。 實(shí)際上，這非常令人驚訝，因?yàn)閖vm不需要通過運(yùn)行程序來了解是否可以進(jìn)行轉(zhuǎn)義分析。 這應(yīng)該通過對(duì)代碼的靜態(tài)分析來證明。

看看這個(gè)代碼（我被思想的啟發(fā)本博客）：

import java.io.IOException; import java.util.Optional;/*** Created by daniel on 17/12/2015.*/ public class Test {private static String NAME;public static void main(String[] args)throws IOException {new Test().test();}public void test() throws IOException {Name name = new Name("Steven");int iterations = 1_000_000;for(;;){countOptional(name, iterations);System.out.println("Press any key to continue");System.in.read();}}private static void countOptional(Name name, int iterations) {for (int i = 0; i < iterations; i++) {NAME = name.getOptionalName().get();}System.out.println(iterations + " optional iterations " + NAME);}class Name {private final String name;public Name(String name) {this.name = name;}public Optional<String> getOptionalName() {return Optional.ofNullable(name);}} }

我們需要確保程序在沒有g(shù)c的情況下運(yùn)行（我建議使用這些標(biāo)志）：

-verbosegc -Xmx4g -Xms4g

當(dāng)程序等待輸入時(shí)，請(qǐng)執(zhí)行堆轉(zhuǎn)儲(chǔ)以查看已創(chuàng)建了多少個(gè)Optional對(duì)象。 然后按任意鍵以恢復(fù)程序。

要執(zhí)行堆轉(zhuǎn)儲(chǔ)，請(qǐng)先運(yùn)行jps以確定程序的pid，然后運(yùn)行：

jmap -histo pid | head

一次不使用-Xcomp標(biāo)志，一次使用-Xcomp標(biāo)志。

沒有-Xcomp標(biāo)志

第一次迭代后：

在第二次迭代之后：

所有后續(xù)迭代都是相同的，不再創(chuàng)建其他對(duì)象：

在234k次迭代之后，顯然有轉(zhuǎn)義分析開始了-不知道為什么要花這么長(zhǎng)時(shí)間，通常（例如，使用編譯代碼）10k次迭代就足夠了嗎？ 同樣在第二次迭代中，它在逃逸分析開始之前又創(chuàng)建了約40萬(wàn)個(gè)對(duì)象，這也有些神秘。

使用-Xcomp標(biāo)志

第一次迭代后：

在第二次迭代之后：

每次迭代后， Optional對(duì)象的數(shù)量增加1m。

摘要

• -Xcomp是幾乎絕對(duì)不應(yīng)在生產(chǎn)中使用的開關(guān)。 我可以想象在某些情況下您可能想禁用解釋器，但是這些情況非常特殊。
• 逃脫分析似乎至少需要進(jìn)行20萬(wàn)次迭代才能有效。 因此，您需要允許超過10k的迭代時(shí)間以進(jìn)行完全預(yù)熱。
• 還有另一個(gè)階段，在逃避對(duì)象之后，似乎需要再次執(zhí)行此操作。 這需要進(jìn)一步的理解。
• 如果通過在兩次調(diào)用Optional之間進(jìn)行一些工作來減慢程序速度，則對(duì)象數(shù)量會(huì)減少。 例如，我發(fā)現(xiàn)對(duì)Math.sin的調(diào)用將Optional對(duì)象減少了約50％。

翻譯自: https://www.javacodegeeks.com/2015/12/long-take-jvm-effect-escape-analysis-maybe-longer-think.html

總結(jié)

以上是生活随笔為你收集整理的jvm需要多长时间才能进行转义分析？ 可能比您想象的要长。的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。