Funktion des JRE

[Mindstream]

Hi,

Ich habe mich jetzt schon etwas länger über das JRE informiert,
aber ich habe immer noch offene Fragen.

Also soweit ich das verstanden habe übersetzt ein Compiler den von
einem Programmierer geschriebenen Quellcode in Bytecode,
um einen Geschwindigkeitsvorteil zu Scriptsprachen zu erzielen, die
vor der Interpretation noch die Programmlogik/Semantik auswerten müssen.
Das hat aber noch nichts mit dem JRE zu tun.

Der JIT übersetzt dann vor dem Start eines Java-Programms den
Bytecode in Plattformabhängigen Maschinencode. Dieser Vorgang
hat die Nachteile, dass der Start verzögert wird und
dass der Speicher das Programm im Speicher halten muss.

Hier kommt bei mir die Frage auf, warum ein in Maschinensprache
vorliegendes Programm nicht lokal (von mir aus versteckt)
als ausführbare Datei gespeichert und ganz normal gestartet wird.
Hat die JVM zur Ausführungszeit immer noch die Möglichkeit
den Programmfluss zu steuern?
Wieso ersetzt man die Kontrollmechanismen dann nicht mithilfe von
mitcompilierten Strukturen? :bahnhof:

Der HotSpot-Compiler ist eine Lösung, die die Vorteile des vor dem JIT
genutzten Interpreters und des JIT-Compilers selbst vereint.
Das heißt, dass der Bytecode nicht vor dem Programmstart übersetzt wird,
sondern wie beim Interpreter zur Laufzeit.
Allerdings gibt es den Unterschied,
dass Performance-kritische Abschnitte des Programms
zur Laufzeit in stark optimierten Maschinencode übersetzt werden.


Ich hoffe, dass ihr dazu einige Ergänzungen/Korrekturen machen und
mir meine Fragen beantworten könnt.

Liebe grüße,
Mindstream.

 

[Campino]

Also soweit ich das verstanden habe übersetzt ein Compiler den von
einem Programmierer geschriebenen Quellcode in Bytecode,
um einen Geschwindigkeitsvorteil zu Scriptsprachen zu erzielen, die
vor der Interpretation noch die Programmlogik/Semantik auswerten müssen.
Das hat aber noch nichts mit dem JRE zu tun.

Jop, der Compiler gehört zum JDK.

Der JIT übersetzt dann vor dem Start eines Java-Programms den
Bytecode in Plattformabhängigen Maschinencode. Dieser Vorgang
hat die Nachteile, dass der Start verzögert wird und
dass der Speicher das Programm im Speicher halten muss.

Jaein. Teilweise wird der Bytecode erst zu Maschinencode, wenn er wirklich gebraucht wird (und nicht das ganze Programm bei Start). Teilweise wird auch der Bytecode interpretiert, also ausgeführt ohne ihn zu übersetzen.

Hier kommt bei mir die Frage auf, warum ein in Maschinensprache
vorliegendes Programm nicht lokal (von mir aus versteckt)
als ausführbare Datei gespeichert und ganz normal gestartet wird.
Hat die JVM zur Ausführungszeit immer noch die Möglichkeit
den Programmfluss zu steuern?
Wieso ersetzt man die Kontrollmechanismen dann nicht mithilfe von
mitcompilierten Strukturen?

Du willst quasi ein in Java geschriebenes Programm direkt in Maschinencode übersetzen, damit du dann zur Laufzeit nicht warten musst, bis es übersetzt ist? Das würde theoretisch gehen, allerdings würdest du dabei die Plattformunabhängigkeit einbüßen.

Der HotSpot-Compiler ist eine Lösung, die die Vorteile des vor dem JIT
genutzten Interpreters und des JIT-Compilers selbst vereint.
Das heißt, dass der Bytecode nicht vor dem Programmstart übersetzt wird,
sondern wie beim Interpreter zur Laufzeit.
Allerdings gibt es den Unterschied,
dass Performance-kritische Abschnitte des Programms

zur Laufzeit in stark optimierten Maschinencode übersetzt werden.

Das ist das was ich oben sagte: Die JVM sagt upps, den Programmteil brauch ich einmal und nie wieder, den interpretier ich, aber den da, den brauch ich alle acht Sekunden, den kompilier ich und führe dann Maschinencode aus, geht schneller.

so, ich hoffe das hilft,
campino

 

[Mindstream]

Hi,

Der JIT übersetzt dann vor dem Start eines Java-Programms den
Bytecode in Plattformabhängigen Maschinencode. Dieser Vorgang
hat die Nachteile, dass der Start verzögert wird und
dass das Programm im Speicher gehalten muss.

Jaein. Teilweise wird der Bytecode erst zu Maschinencode, wenn er wirklich gebraucht wird (und nicht das ganze Programm bei Start). Teilweise wird auch der Bytecode interpretiert, also ausgeführt ohne ihn zu übersetzen.
[...]

[Der HotSpot-Compiler übersetzt den Code auch während der Laufzeit]

Das ist das was ich oben sagte: Die JVM sagt upps, den Programmteil brauch ich einmal und nie wieder, den interpretier ich, aber den da, den brauch ich alle acht Sekunden, den kompilier ich und führe dann Maschinencode aus, geht schneller.

Ich bin davon ausgegangen, dass der JIT und der HotSpot-Compiler sich unter anderem im Zeitpunkt der Kompilierung/Interpretation des Programms unterscheiden. Ich meinte mit dem JIT-Compiler die Technologie, die vor der HotSpot-Technologie verwendet wurde. Du scheinst die Begriffe HotSpot-Compiler und JIT-Compiler nicht zu unterscheiden. :?:

Du willst quasi ein in Java geschriebenes Programm direkt in Maschinencode übersetzen, damit du dann zur Laufzeit nicht warten musst, bis es übersetzt ist? Das würde theoretisch gehen, allerdings würdest du dabei die Plattformunabhängigkeit einbüßen.

Zumindest nachdem das Programm einmal übersetzt wäre müsste man nicht mehr warten. Das Argument mit der Plattformunabhängigkeit hatte ich schon erwartet. Deshalb habe ich geschrieben, dass es versteckt sein könnte (in sofern, dass der User keinen direkten Zugriff darauf hat, sondern nur über das JRE darauf zugreifen kann). Somit wären die Programme immer noch nur als Bytecode sichtbar, also auch plattformunabhängig. Außerdem wäre der Bytecode ohne die Kontrollstrukturen auch wesentlich kleiner als die ausführbare Datei.

 

[kopfsalat]

Hi!
Hier ein paar Anmerkungen zu deinem Posting:

Der JIT übersetzt dann vor dem Start eines Java-Programms den Bytecode in Plattformabhängigen Maschinencode. Dieser Vorgang hat die Nachteile, dass der Start verzögert wird ...

Das Programm wird nur Stück für Stück bei Bedarf kompiliert.

und dass der Speicher das Programm im Speicher halten muss.

Auch bei Maschinensprachenprogrammen wird beim Start das gesamte Programm in den Speicher geladen und dort gehalten.

Hat die JVM zur Ausführungszeit immer noch die Möglichkeit
den Programmfluss zu steuern?

Compiler die zur Laufzeit arbeiten, können mit einigen Tricks aufwarten, die normalen (Ahead-Of-Time) Compilern nicht möglich sind. Z.B. können lange nicht mehr veränderte Variablen als Konstanten oder aufgrund frühen Abbrüchen kurz gewordene Methoden als Makros in-place ersetzt werden, bis die Abbruchsbedingung nicht mehr gilt, Codeblöcke gemäß aktuellen Parametern optimal compiliert werden um bei deren Änderung neu zu kompilieren, Schleifen können entrollt werden um die langsamen Sprungbefehle wegzurationalisieren und das ganze geht soweit, dass einzelne Sprungvorhersagen intelligenter getroffen werden können, um Pipelining besser zu unterstützen. Solcherart Optimierungen können dann bei sich veränderden Umgebungen neu getroffen werden.
Wie sehr sich diese Dinge auf die Laufzeit unterm Strich auswirken weiß ich allerdings nicht. Aber JIT-Compiler sind nach wie vor Gegenstand der Forschung.

Vielleicht wäre es ja sogar sinnvoll, dass beim ersten Aufruf eines .class-files dieses in eine .dll/.so-Datei kompiliert wird, welche dann bei jedem weiteren Start direkt aufgerufen und angebunden wird. Ich könnte mir aber vorstellen, dass es dabei dann zu irgendwelchen bösen Schwierigkeiten kommen wird: z.B. um Ressourcen beliebig im Netz auf zentralen Servern zu verteilen und getrennt voneinander zu pflegen, sowie die Möglichkeit, Sicherheitspolicen zu erstellen, um die Rechte der Software gezielt einzuschränken (Im Gegensatz zu ständig überwachten Programmen können Maschinencodeprogramme nur einmalig zum Zeitpunkt der Compilierung überprüft werden, aber eine Reaktion auf beliebige komplexe Usereingaben ist übelst schwer bis gar nicht zu kontrollieren (es sei denn, sie machen ebenfalls laufend zwischendrin Sicherheitschecks, aber dann ist man ja schon bei einer Selbstkontrolle und verlagert die JRE einfach ins Programm selbst)), und auch die gesamte Garbage-Collection stelle ich mir schwer bis unmöglich vor, ohne eine kontrollierende Instanz im Hintergrund (die JRE).

Außerdem denke ich, dass das keinen Geschwindigkeitsvorteil mehr bringen würde, da der Abstand von Java zu reinen Maschinencodeprogrammen mittlweile sowieso marginal ist.

Auch vom Grundansatz her finde ich eine über dem Programm stehende Instanz, die dieses zur Laufzeit stets analysiert und optimiert sehr sinnvoll um sichere und schnelle Software zu ermöglichen. Selbst MS scheint mit Managed Code einen ähnlichen Weg in Zukunft gehen zu wollen.

 

[Mindstream]

Ich glaube ich habe es jetzt verstanden.
1. Der JIT-Compiler
-übersetzt das Programm auch während der Ausführung des Programms
-behält, ähnlich wie bei ausführbaren Dateien, nicht das gesamte Programm im Speicher
2. Das übersetzen des Bytecodes in eine ausführbare Datei
(auf Systemen ohne Java-Prozessor )
bringt heutzutage einen zu vernachlässigenden Geschwindigkeitsvorteil, wenn überhaupt.
Eigentlich habe ich gemeint, warum man es früher nicht gemacht hat,
als die Performance noch ein größeres Problem war,
was aber nun auch schon beantwortet wurde:
Das Einbinden der Kontrollmechanismen der JVM
scheint wegen der Umsetzung der Sicherheits-Policies extrem schwer zu sein.

Allerdings gibt es einen Garbage-Collector auch für ausführbare Dateien.
Und zumindest herkömmliche Überläufe bei der Eingabe
werden durch die Programmiersprache Java verhindert,
weil sie keinen direkten Speicherzugriff erlaubt
und Array Grenzen überwacht werden.
Das ließe sich sicherlich auch ohne JRE realisieren lassen.
Aber eine Debatte darüber hat wahrscheinlich keinen realen Wert,
schließlich gibt es das JRE und das hat wohl kaum Nachteile
gegenüber einer mit Kontrollstrukturen vollgemüllten ausführbaren Datei.


Danke für eure Hilfe! :applaus:

 

[kopfsalat]

Ahoi nochmal!

behält, ähnlich wie bei ausführbaren Dateien, nicht das gesamte Programm im Speicher

Wenn eine ausführbare Datei gestartet wird, so wird sie komplett in den Speicher geladen und bleibt dort bis zur Beendigung des Prozesses. Wenn zur Laufzeit libraries dazugeladen werden, werden diese ebenfalls komplett in den Speicher eines jeden aufrufenden Prozesses geladen. Damit befinden sich auch alle möglichen Dinge im Speicher, die ggf. überhaupt nicht genutzt werden. Intensiver Einsatz von Library-Bildung oder ganz andere Konzepte wie COM schaffen hier dann Abhilfe.

Bei Java wird erst dann (durch den ClassLoader) eine Klasse in den Speicher geladen, wenn sie instanziiert (oder bei statischen Methoden referenziert) wird und kann durch den GarbageCollector auch wieder komplett rausgeschmissen werden. Damit befindet sich nur genutztes Zeug im Speicher. Das allererste Laden einer Klasse könnte daher aber minimal länger dauern, allerdings arbeitet auch hier die JVM vorausschauend, also lädt die Klassendefinition schonmal ein wenn abzusehen ist, dass sie benötigt werden wird. Die meiste Zeit während einer normalen Programmausführung ist ja eh nur Leerlaufzeit, in der sich die JVM dann ein wenig um Optimierungen, etc. kümmern kann.

 

[Wildcard]

Bei Java wird erst dann (durch den ClassLoader) eine Klasse in den Speicher geladen, wenn sie instanziiert (oder bei statischen Methoden referenziert) wird und kann durch den GarbageCollector auch wieder komplett rausgeschmissen werden.

Kannst du das mit einer Quelle belegen? Ich war der Meinung das der GC Klassen nicht entlädt.

 

[kopfsalat]

Jetzt habe ich es wiedergefunden! Ich hatte da mal sowas in der Richtung gelesen, aber wohl etwas verfälscht in Erinnerung:
Klar, dass der GC Objekte entfernen kann. Aber Klassendefinitionen selbst kann er nicht entfernen, nichteinmal der ClassLoader selbst. Sind sie einmal eingeladen, so bleiben sie im Speicher (macht ja auch Sinn, damit Klassenvariablen gespeichert bleiben.) Eine Ausnahme gibt es aber: Verwendet man einen eigenen ClassLoader und gibt es keine durch ihn erstellten Instanzen mehr und auch auf den Classloader keine Referenzen mehr, so wird er mitsamt seiner von ihm geladenen Klassendefinitionen rausgeschmissen.

Hier ein Link dazu: http://www.galileocomputing.de/open...sel08_005.htm#Rxx747java080050400029E1F02F1D1

 

[Wildcard]

Verwendet man einen eigenen ClassLoader und gibt es keine durch ihn erstellten Instanzen mehr und auch auf den Classloader keine Referenzen mehr, so wird er mitsamt seiner von ihm geladenen Klassendefinitionen rausgeschmissen.

Jau, das war mir schon klar, sonst würden ja das schöne Hot-Code-Replacement in Eclipse nicht funktionieren :wink: