Speicherlayouts eines Interpreters verstehen (JVM/JS)

Question

Ich versuche das Speicherlayout eines Prozesses auf Betriebssystemebene zu verstehen und wir sind an dieses Diagramm gewöhnt.

Vergessen Sie den Multithreading-Teil des Diagramms, aber jetzt für allgemeine Zwecke, nehmen wir an, dass der "Code" -Block im obigen Diagramm die binären Anweisungen unseres Programms ist. Dies setzt voraus, dass der Code bereits kompiliert wurde, um jetzt in seiner binären Form verfügbar zu sein. Aber was ist mit interpretierten Sprachen, z.B. ein Bytecode, der vom JVM-Interpreter ausgeführt wird. Während ich hier den JVM-Interpreter auswähle, ist meine Frage für jede interpretierte Sprache und wie passt sie in das oben gezeigte Diagramm. Mein Verständnis ist, dass der Interpreter selbst ein Programm ist und daher in dem Codeblock sitzen muss, der im obigen Diagramm gezeigt wird, und das .class-Programm im Falle von Java oder einer .js-Datei im Falle von Javascript-Interpretern ist das "Argument" so sprechen Sie, dass dieser Dolmetscher arbeitet, um sie in OS/Maschine verständlichen Code zu übersetzen, der dann ausgeführt wird. Fordern Sie Ihre Gedanken dazu auf.

Answer 1

Es ist eine Frage der Perspektive, ob Sie Bytecode "Code" betrachten würden. Die Terminologie ist etwas unscharf.

Der "Code" im Diagramm ist nativer ausführbarer Code, d. H. Ihr Interpreter. Was die CPU und das Betriebssystem betrifft, ist dies der einzige Code, der jemals ausgeführt wird. Für den OS ist der Bytecode, der interpretiert wird, einfach Daten, auf denen der tatsächliche native Code arbeitet.

In diesem Fall sind die Daten eine Form von Anweisungen sowie ein Detail, das die CPU nicht bewusst ist und nicht kümmert.