Diskussion:Java Virtual Machine
aus Wikipedia, der freien Enzyklopädie
Kurze Frage: Ist es nicht vielmehr so, dass die JVM Objektcode in Bytecode "umrechnet", damit der Prozessor den Bytecode ausführen kann ?? --DaB. 18:44, 10. Feb 2003 (CET)
- Uh, Vorsicht mit den Begriffen. Bytecode ist ein neu erfundener Begriff, er bezeichnet direkt den Code, den die JavaVM ausführt. Objektcode ist IMHO jede binäre zum Linken vorbereitete Form von Code, also auch Bytecode. Zur Frage: Die VM führt den plattformunabhängigen Bytecode aus, dabei kann sie JIT's verwenden, die den Bytecode in den jeweiligen Maschinencode übersetzen. Ich hoffe Dir wurde geholfen. :-) -- Dishayloo 23:13, 2. Jun 2003 (CEST)
Eine Bemerkung zum "sinnfreien Satz": Wie soll ein Computer denn _irgendetwas_ auswerten, wenn er es nicht parst, zumal wir hier von einem _Interpreter_ sprechen, der Bytecode in Maschinencode umsetzt... Darüber hinaus führte _exakt dieser Parseroverhead_ zur Entwicklung der dynamisch optimierenden Hotspot-Engine, welche Bytecode in Maschinencode umsetzt und somit das wiederholte Parsen des Bytecodes überflüssig machte.
Gruß HbJ
- siehe Parser (Informatik) oder http://www.wikipedia.org/wiki/Parser (ausführlicher). Hier wird von Quelltexten, bzw. einer grammatischen Struktur gesprochen. Bytecode hat keine grammatische Struktur, er wird einfach sequentiell abgearbeitet. Ein JPG-Bild wird ja auch nicht geparst. Der Bytecode wird interpretiert oder dekodiert, das stimmt. :-) Das mit dem Geschwindigkeitsnachteil stimmt so nicht einmal, da mit JITs heute die VMs schneller arbeiten als kompilierter Java-Code. Schliesslich war es ein langer Satz mit wenig Substanz. Aus all diesen Gründen habe ich ihn gelöscht, und nur den letzten genannt (Bequemlichkeit). Ist so klarer, was ich meinte? -- Dishayloo 00:28, 3. Jun 2003 (CEST)
Schon klar. Mir ging es um die (Stein)zeit, als der Java-Bytecode noch vollständig und ohne Optimierungen interpretiert wurde (so wie die Token beim seligen Locomotive BASIC) und somit Rechenzeit für das "Verarbeiten" (whatever) des Bytecodes und das Auswerfen des Maschinencodes draufging, was der Hauptapplikation Rechenzeit stahl (Soweit ich weiß, gab es Mitte der 90er einige böse Artikel zur schlechten Performanz verschiedener VMs, was unter anderem diesem Umstand angelastet wurde). Mein Verweis auf Hotspot sowie die modernen JIT-Architekturen (mit dynamischer Optimierung inklusive Profiling und "Einstellen" auf die Stärken und Schwächen des jeweiligen Prozessors!) zeigt wohl, dass ich die modernen Ansätze keinesfalls verurteilt habe. Darüber hinaus muss zumindest der Verifier parsen, weil er mittels seiner Sicherheitsrichtlinien (die man durchaus als Meta-Grammatik sehen könnte) illegalen Code fernhalten muss. Zum Parsen von JPEG empfehle ich LinuxSecurity.
Vielleicht ist der Begriffsgebrauch nicht 100-prozentig korrekt, aber durchaus üblich.
(Mental note to myself: Bin schon wieder dabei, mich umbeliebt zu machen). Sorry ;-)
EDIT: Die Suchworte java bytecode parser ergeben viele schöne Links. Hier einige davon:
Jadcentral C#-based parser for Java bytecode
Sourceforge (Class file reader and parser) Class-Files sind Bytecode, oder?
gcc.gnu.org Bytecode parser fails on 64-bit systems
Gruß HbJ 00:53, 3.Juni 2003 (CEST)
- Hmm, da scheint der Begriff doch unterschiedlich verwendet zu werden. Entschuldigung, ich kannte 'parsen' nur für Quelltexte. Tut mir leid. (ô_ô) -- Dishayloo 09:18, 3. Jun 2003 (CEST)
Kein Problem ;-) Es gibt sogar eine (logische?) Erklärung, warum auch Bytecode "geparst" wird: Das Prinzip der Statusmaschine (Hurra, zwei Status: Okay und Fehler). Selbst der Bytecode-Parser muss zwischen legalen und illegalen Codeworten unterscheiden. Außerdem erfolgt ja eine Substitution des Bytecode durch Maschinencode, was nach formalen Ersetzungsregeln geschieht, in die _theoretisch_ sogar die Elimierung redundanter Anweisungen eingeschlossen sein _könnte_ (für händisch erzeugten oder schlecht optimierten Bytecode).
Im Endeffekt stehen wir hier vor dem gleichen Problem wie in der OOP: Gleiche Begriffe für unterschiedliche Sachverhalte (zwei Bücher, drei Terminologien. Argh!).
Ach ja: Frieden! ;-)
HbJ 14:15, 3. Jun 2003 (CEST)
Müsste im Artikel nicht auch kurz die JVM von Microsoft und der damit verbundene Streit mit "Sun" erwähnt werden?
