![](/img/trans.png)
[英]Can Hotspot JIT optimizations for fast throw exceptions lead to ambiguous results?
[英]Hotspot JIT optimizations
在關於Hotspot中的JIT的講座中,我想盡可能多地給出JIT執行的特定優化的示例。
我只知道“方法內聯”,但應該有更多。 為每個例子投票。
好吧,你應該掃描Brian Goetz的文章作為例子。
簡而言之,HotSpot可以並且將會:
synchronized
塊 volatile
變量的內存寫入 等等
有關現代JVM在Jikes RVM站點上使用的優化的精彩演示: ACACES'06 - 虛擬機中的動態編譯和自適應優化
它討論了架構,權衡,測量和技術。 並且至少列出了JVM為優化機器代碼所做的20件事。
我認為有趣的東西是傳統編譯器不能與JIT相反的東西。 內聯方法,消除死代碼,CSE,實時分析等都是由你的普通c ++編譯器完成的,這里沒什么“特別的”
但是,基於樂觀的假設來優化某些東西,如果結果出現錯誤,那么以后會進行去優化? (假設一個特定的類型,刪除將在以后無論如何都會失敗的分支,...)如果我們可以保證目前只存在一個類(同樣只能在去優化中可靠地工作的東西),刪除虛擬調用? 自適應優化是我認為真正區分JIT與mill c ++編譯器運行的一件事。
也許還提到了JIT完成的運行時分析,以分析它應該應用哪些優化(不過那時所有的配置文件引導的優化都不再那么獨特)。
有一個古老的,但可能仍然有效概述這篇文章 。
亮點似乎是基於可用的運行時分析信息執行經典優化:
還有一些次要的,比如代際GC,這使得分配短壽命對象更便宜,以及各種其他更小的優化,以及自該文章發布以來添加的任何其他內容。
還有一個更詳細的官方白皮書 ,以及一個相當細致的HotSpot Internals wiki頁面 ,其中列出了如何編寫快速Java代碼,以便您可以推斷出優化的用例。
跳轉到等效的本機機器代碼而不是操作碼的JVM解釋。 對於Java應用程序的大量使用部分(相當於JVM的擴展)而言,不需要在機器代碼中模擬機器(JVM)提供了良好的速度提升。
當然,這就是HotSpot的大部分內容。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.