Was sind die Unterschiede in JIT zwischen Java und. NET

Question

Ich weiß, dass Microsoft .NET die CLR als JIT-Compiler verwendet, während Java den Hotspot hat. Was sind die Unterschiede zwischen ihnen?

Answer 1

Sie sind sehr unterschiedliche Tiere. Wie die Leute darauf hingewiesen haben, kompiliert die CLR den Maschinencode, bevor sie ein Stück MSIL ausführt. Dies ermöglicht neben der typischen Eliminierung von Dead-Code und der Abgrenzung von privaten Optimierungen die Nutzung der CPU-Architektur des Zielrechners (obwohl ich mir nicht sicher bin, ob dies der Fall ist). Dies führt auch zu einem Treffer für jede Klasse (obwohl der Compiler ziemlich schnell ist und viele Plattformbibliotheken nur eine dünne Schicht über der Win32-API sind).

Die HotSpot VM verfolgt einen anderen Ansatz. Es besagt, dass der Großteil des Codes selten ausgeführt wird, daher lohnt es sich nicht, Zeit mit der Kompilierung zu verbringen. Der gesamte Bytecode startet im interpretierten Modus. Die VM führt Statistiken auf Call-Sites und versucht Methoden zu identifizieren, die mehr als eine vordefinierte Anzahl von Malen aufgerufen werden. Dann kompiliert es nur diese Methoden mit einem schnellen JIT-Compiler (C1) und tauscht die Methode aus, während sie läuft (das ist die spezielle Soße von HS). Nachdem die C1-kompilierte Methode einige Male aufgerufen wurde, wird dieselbe Methode mit einem langsamen, aber komplizierten Compiler kompiliert und der Code wird im laufenden Betrieb wieder ausgetauscht.

Da HotSpot Methoden austauschen kann, während sie ausgeführt werden, können die VM-Compiler spekulative Optimierungen durchführen, die in statisch kompiliertem Code nicht sicher sind. Ein kanonisches Beispiel ist das statische Dispatching/Inlining monomorpher Aufrufe (polymorphe Methode mit nur einer Implementierung). Dies geschieht, wenn die VM sieht, dass diese Methode immer zum selben Ziel aufgelöst wird. Was früher ein komplexer Aufruf war, ist auf ein paar CPU-Anweisungen beschränkt, die von modernen CPUs vorhergesagt und weitergeleitet werden. Wenn die Schutzbedingung aufhört, wahr zu sein, kann die VM einen anderen Codepfad verwenden oder sogar in den Interpretiermodus zurückfallen. Basierend auf der Statistik und der Programmauslastung kann der generierte Maschinencode zu unterschiedlichen Zeiten unterschiedlich sein. Viele dieser Optimierungen basieren auf den während der Programmausführung gesammelten Informationen und sind nicht möglich, wenn Sie beim Laden der Klasse einmal kompilieren.

Aus diesem Grund müssen Sie die JVM aufwärmen und eine realistische Arbeitslast emulieren, wenn Sie Algorithmen bewerten (schiefe Daten können zu einer unrealistischen Bewertung der Optimierungen führen). Weitere Optimierungen sind Lock Elision, adaptive Spin-Locking, Escape-Analyse und Stack-Allocation usw.

Das heißt, HotSpot ist nur eine der VMs. JRockit, Azul, IBM J9 und das rücksetzbare RVM, - alle haben unterschiedliche Leistungsprofile.