jvmjit編譯存在哪裡

A. V8編譯生成的機器碼究竟是什麼

實際上V8的JIT編譯器是直接在內存中生成機器碼的，並不會先生成文本形式的匯編然後再使用匯編器去轉換為機器碼。「動態生成機器碼」聽起來可能有點玄乎，其實根本沒啥，就是往內存里寫位元組，這些位元組正好是某些機器碼的意思，然後把這塊內存當作函數去調用就是了。由於代碼自身就是動態生成的，在生成的代碼里直接嵌入resolve好的各種值其實就相當於傳統編譯流程里的「動態鏈接」的效果。順手放倆我以前博客的傳送門：V8實際上自帶一個用C++實現的「匯編器庫」用來動態生成機器碼。它並不把文本形式的匯編轉換為機器碼，而是提供一組C++ API，調用這個API的函數就可以在內存里生成機器碼來。有興趣的同學可能會知道，V8的MacroAssembler庫源自Animorphic的Strongtalk VM，而Strongtalk VM也是HotSpot JVM的前輩。V8 Design Elements文檔里所描述的是最初期的V8的狀態。當時的V8隻有一個JIT編譯器，一個JavaScript函數通常只會被JIT編譯一次。這個JIT編譯器做的優化也不是很多。後來V8演化為擁有兩個JIT編譯器，一個初級編譯器（baseline compiler，名字叫做Full Code Generator，簡稱FullCodeGen），和一個優化編譯器（optimizing compiler，名字叫做Crankshaft），兩個編譯器結合在一次構成雙層編譯。JavaScript函數通常會先被FullCodeGen編譯，然後如果還繼續執行很多次的話則會再被Crankshaft重新編譯一遍，生成更優化的代碼。在這個架構中，FullCodeGen里生成的代碼還是跟V8 Design Elements的相似，會通過inline cache來實現property access；而這些inline cache不但用於實現fast property access，更重要的是它們會被用於收集profile，然後等到Crankshaft編譯的時候，它就可以看先前收集的profile來做profile-guided optimization。以這個 function foo(p) { return p.x } 為例，參數p沒有任何特別的地方，所以JavaScript引擎也無法知道p到底可能有怎樣的值。但通過FullCodeGen生成的代碼所收集到的profile信息，Crankshaft再去編譯 foo() 的時候就可以知道p之前通常指向一個Map（hidden class）為0x2c97ccb179d1的類型的對象。這個類型的constructor為Point、[[Prototype]] 為Point.prototype、對象里有足夠空間容納10個內嵌的欄位（in-object property），並且其中2個slot被用於存儲Smi類型，剩餘的8個slot未被使用。