Wenn der jvm (Hotspot in meinem Fall) bestimmte Codepfade permanent in den Maschinencode übersetzt, wo wird dieser Maschinencode gespeichert? im .text-Segment des Prozessspeichers? im Heap des Prozesses ??
Ich spreche nicht über JITing. Nach meinem Verständnis wird JIT Bytecode kompilieren und ausführen, ohne den kompilierten Code irgendwo zu speichern. Aber was ist, wenn der jvm diesen Code speichert - wo im Prozessraum speichert er es?
... wie die Kommentare und Antworten zeigen, ist alles, wonach ich gefragt habe, tatsächlich ein Teil von JIT.
BEARBEITEN:
Gemäß meinem Kommentar unten ist die Situation, auf die ich hier besonders Bezug nehme, hier als "Adaptive Optimierung" dokumentiert: Ссылка
Erstens, was Sie beschreiben, ist JIT - speziell wie es in Hotspot
funktioniertUm Ihre Frage zu beantworten, wo der Code gespeichert wird zur Laufzeit - er befindet sich im Prozess-Heap und die Zeiger auf den Methodencode in der Klass-Datei des Objekts werden aktualisiert, um darauf zu zeigen. Es gibt auch etwas namens OSR (on stack replacement) zum Kompilieren lang laufender Schleifen direkt auf dem Stack.
Ich habe nicht mit VMs in Produktionsqualität gearbeitet, aber hier sind meine fünf Cent.
.text Abschnitte in ausführbaren Unix-Dateien gehören zu der Datei , die ausführbaren Code speichert; zur Laufzeit wird dieser Dateiabschnitt einem Speicherbereich zugeordnet, der vom System-Linker während der Programminitialisierung zugewiesen wurde, das ist alles (unter Linux können Sie das Layout der Abschnitte im Speicher in /proc/$PID/maps sehen).
Wie bei der JIT-Kompilierung auf Unix-ähnlichen Systemen kann ich nur an Speicherbereiche denken, die von % co_de zugewiesen wurden % Systemaufruf mit aktiviertem% co_de% -Flag. Dieser Aufruf wird von POSIX-Standards spezifiziert und vom Linux-System-Linker mmap verwendet, um eine native ausführbare Datei in den Speicher zu laden. Dieser Aufruf kann gleichermaßen zum Zuweisen neuer ausführbarer Speicherbereiche zur Laufzeit verwendet werden.
Der übliche Heap wird oft durch OS / MMU vor der Ausführung geschützt, wie jede PROT_EXEC -Datei vorschlägt:
hier ld.so bedeutet, dass keine Daten in /proc/$PID/maps ausgeführt werden können (z. B. ist dies bei 32-Bit x86-CPUs ohne PAE nicht der Fall, sie haben jedoch keine Hardware-Fähigkeit, um die Ausführung einiger Speicherdaten zu verhindern als Code), kann aber gelesen / geschrieben werden.
Eine VM benötigt also einen dedizierten Speicherbereich mit Code-Ausführungsberechtigung. In der Tat suchen wir nach rw-p Speicherbereichen in einem Java-Prozessspeicher-Layout:
Dann ist die Ausführung von nativem Code eine Frage der Assemblierung von JIT-kompiliertem nativen Code entweder positionsunabhängig (wie kompilierter Objektcode, mit [heap] option rwx ) oder unter Verwendung der von gcc zurückgegebenen Adresse.
Tags und Links java memory process jvm-hotspot jvm