2008-09-12 8 views
17

Was ist der Unterschied zwischen den internen Funktionen von Java JVM und .NET CLR?Was ist der Unterschied zwischen den internen Funktionen von Java JVM und .NET CLR?

Vielleicht wäre ein Ausgangspunkt, sind sie im Grunde die gleiche Sache in ihren jeweiligen Umgebungen (Java> JVM> Maschinencode) (C#> CLR> IL).


Update: Einige Leute haben auf die Punkte erwähnt ich zu decken versuchte:

  1. Garbage Collection
  2. Boxen/Unboxing
  3. JIT-Debuggen
  4. Generics/Templates
  5. Bitte zögern Sie nicht, andere gute Themen, die zu unterscheiden die Zwei.

@George Mauer - das klingt sehr interessant:

Schon dies einmal geschrieben, aber hier ist ein series of interviews mit C# Chefsprache Designer Anders Hejlsberg.

+0

Ich schlage vor, eine neue Frage mit dem Betreff zu beginnen, der Sie am meisten interessiert, indem Sie auf diese Frage verweisen. So kann es jedes Thema tiefer abdecken, wenn es Experten gibt. –

Antwort

5

schon dies einmal geschrieben, aber here is a series of interviews mit C# Chefsprachdesigner Anders Hejlsberg. Obwohl meist über die Unterschiede zwischen C# reden und Java er tut tauchen Sie ein in Unterschiede zwischen den virtuellen Maschinen als auch.

+0

Ich hatte eine Chance zu sehen, wie dieser Typ in meiner Schule sprach und ich blies es ab. Bereue das jetzt wirklich. –

6

Von here. Ich hätte es nicht besser sagen können (Nun, mit Ausnahme eines Flammenkrieges ist dies ein flammenloser Ort :-)).

Hallo,

auf Ihre Frage reagieren scheint voller Gefahren durch eine Flamme Krieg zu beginnen, also werde ich vorsichtig vorgehen.

Es gibt eine Reihe von grundlegenden technischen Ähnlichkeiten zwischen dem Java Runtime und der Common Language Runtime, einschließlich Müll gesammelt Speicher, eine Zwischensprache (Microsoft IL im Vergleich zu Java-Bytecode), Core-System-Bibliotheken und Unterstützung für ziemlich hohe Sprachen, Code Sicherheit und Bereitstellung.

jedoch jede dieser ‚ähnlich‘ Bereiche haben auch eine Reihe von beträchtlichen und kleine Unterschiede, und es ist über die Rahmen eines einfachen Forum Beitrag beschreiben die meisten von ihnen.

würde ich vorschlagen, eine targetted Frage zu einem der verschiedenen Runtime-Funktionen und Komponenten Bereiche (zB Speicherverwaltung, Kompilation, Systembibliotheken, Sicherheit, etc.) zu fragen und dann können wir ein liefern Zielantwort (zB ein Blog, ein technischer Artikel oder einige Bücher).

9

Dies sollte ein guter Thread sein.

Einer der größten Unterschiede zwischen dem CLR und JVM ist die CLR "s native Integration von Generika.

Java, anstatt die generischen Typen entfernt und die JVM kann nur mit Objekten arbeitet, indem sie die Objekte Autoboxing es scheint Pseudo-Generika sein.

+1

Nicht sicher. Typ löschen ist ziemlich wichtig, dachte ich. –

0

wie Vinko sagte, die vollständigen Details sind so über den Rahmen eines Forums hinaus. Die Unterschiede/Gemeinsamkeiten laufen darauf hinaus:

Sie sind beide eine Laufzeitumgebung "Sandbox", die einen "Just-in-Time" -Compiler enthalten, um Programmanweisungen in einer Zwischensprache (MSIL oder ByteCode) in nativen Maschinencode zu übersetzen und bieten automatische Speicherverwaltung (Garbage Collection). Zusätzlich zu den jeweiligen Laufzeitumgebungen gibt es eine Reihe von Klassenbibliotheken, die den Entwicklern Abstraktionen auf höherer Ebene bieten, um Entwicklungsaufgaben zu vereinfachen.

Die Interna, wie diese Laufzeitumgebungen tatsächlich implementiert werden, sind zum größten Teil proprietär für Microsoft und Sun. Die Algorithmen, die beispielsweise von den Speicherbereinigungssystemen verwendet werden, während sie in der technischen Funktionalität wahrscheinlich ähnlich sind, unterscheiden sich in der Implementierung.

1

Miguel de Icaza erwähnt here:

Seasoned Industrie Programmierer werden feststellen, dass die oben ist sehr ähnlich wie Java und der Java-VM. Sie haben recht, das obige ist genau wie Java.

Die CIL hat eine Funktion allerdings nicht in Java gefunden: es ist Byte-Code-Darstellung, die leistungsfähig genug ist, um als Ziel für viele Sprachen verwendet werden: von C++, C, Fortran und Eiffel und Haskell Lisp einschließlich Dinge wie Java, C#, JavaScript und Visual Basic in der Mischung.

Ich wünschte, ich hätte die Zeit, um ausführlicher zu gehen, aber aus Gründen dieses Arguments genügt das obige.

Die Kommentare gehen in einige Details, wie zum Beispiel Tail-Call-Optimierungen. Viele haben sich seit 2002 geändert - sowohl CLR als auch JVM haben jetzt mehrere Sprachen, die darauf abzielen. Aber trotzdem eine Lektüre wert.

+0

hm ... ich bin mir nicht sicher, dass es ziemlich relevant ist, und das heutzutage am wenigsten (die Antwort wurde vor 2 Jahren gepostet). Fürs Erste haben wir einen Clojure, einen Dialekt von Lisp, und haben immer noch Rhino (was ein JavaScript ist) und zahlreiche Sprachen wie Groovy und Scala. – 0100110010101

+0

Die Frage, ob Tail-Call-Optimierung oder Inline-Din- ge zu machen ist, ist interessant, da ein Stacktrace einige Vorteile haben kann, die garantiert die Realität repräsentieren. Man könnte Metadaten verwenden, um zu bewirken, dass inlinierte Routinen in einer Stapelablaufverfolgung als Aufrufe erscheinen, aber Endanrufe erfordern, dass der generierte Code die Verschachtelungsebene verfolgt. Die Verwendung einer lokalen Variablen für diesen Zweck ist möglicherweise billiger als die Verwendung verschachtelter "Aufruf" -Instruktionen, aber man müsste dann entscheiden, wie man sie auf der Stapel-Ablaufverfolgung darstellt. Wenn die rekursive Tiefe auf den tatsächlichen Stack beschränkt ist ... – supercat

+0

... ist das eine vernünftige Grenze für die Länge eines Stack-Trace. Im Gegensatz dazu, wenn eine Routine Tail-Call Millionen von Ebenen tief rekursiv abrufen könnte, wäre die Erweiterung dieser Aufrufe in einem Stack-Trace absurd. – supercat

2

Ein wesentlicher Unterschied ist, dass die JVM portabel ist über Plattformen und läuft auf Linux, Macintosh und vielen Handys und Embedded-Geräten.

CLR kann auf Microsoft-unterstützten Plattformen ausgeführt werden, wobei das Mono-Projekt einige ältere Versionen von CLR teilweise unterstützt.

Intern bedeutet dies, dass die Leistung der JVM auf diesen verschiedenen Plattformen basierend auf den von den Plattformen bereitgestellten Funktionen variiert.

+0

Da der CTS und der CIL, die die Nicht-Implementierungsdetails der CLR umfassen, ein offener Standard sind, wie jetzt die JVM, ist der einzige wirkliche Unterschied zwischen ihnen aus Sicht der Portabilität, dass mehr Anbieter eine JVM implementieren als eine CLR. Nicht unbedeutend, vor allem angesichts der Tatsache, dass die Pragmatik von MS die De-facto-Implementierung hat, aber es ist hier nicht so, als ob es sich hier um offenen oder proprietären Code handelt. – codekaizen

+0

Java kann auf vielen Plattformen portierbar sein, aber nach meiner Erfahrung ist es nicht einfach portierbar, zumindest über Linux und Windows. Ich arbeite für ein E-Commerce-Unternehmen und eines der Produkte, die wir verwenden, um unsere Website zu betreiben, hat uns viel Kummer bereitet und der Anbieter beschwert sich darüber, dass wir sein Java/Linux-Produkt auf Windows-Servern ausführen. –

0

Soweit ich weiß, hat .Net CLR immer noch viel flexiblere und leistungsfähigere Code Access Security in der Runtime integriert, wodurch viel feinere Rechte und Ausführungsrichtlinien möglich sind.

-1

Dort Unterschiede in Garbage Collection sowie. JVM verwendet Kopieren Kollektor und Markieren und Sweep. .NET-Benutzer Kollektor kopieren und markieren und komprimieren (viel schwieriger zu implementieren).

Auch Typ von Flyswat genannten Löschung ist wichtig. JVM hat keine Ahnung von Generika und alles ist Objekt und zugehörige Perf. Strafe für Boxen und Unboxing. Auch Reflektion gibt Ihnen keine generischen Informationen. CLR unterstützt nativ Generics.

2

Die CLR und JVM haben Ziele und Philosophien, die sich mehr unterscheiden, als Sie vielleicht denken. Im Allgemeinen zielt die JVM darauf ab, dynamischeren Code auf höherer Ebene zu optimieren, während die CLR mehr Low-Level-Tools zur Verfügung stellt, um diese Art von Optimierungen selbst durchzuführen.

Ein gutes Beispiel ist die Stapelzuweisung. Auf der CLR haben Sie eine explizite Stapelzuordnung von benutzerdefinierten Werttypen. Auf der JVM sind die einzigen benutzerdefinierten Typen Referenztypen, aber die JVM kann mithilfe von Escape Analysis unter bestimmten Umständen Heap-Zuordnungen zu Stack-Zuordnungen konvertieren.

Ein anderes Beispiel. In Java sind Methoden standardmäßig virtuell. Zumindest auf C# nicht. Es ist viel schwieriger, virtuelle Methodenaufrufe zu optimieren, da der Code, der an einer bestimmten Aufrufstelle ausgeführt wird, nicht statisch ermittelt werden kann.

Unter der Haube sind ihre Ausführungssysteme ziemlich unterschiedlich. Die meisten JVMs (insbesondere Hotspot) beginnen mit einem Bytecode-Interpreter und nur mit JIT kompilieren Teile des Codes, die z. enge Schleifen. Sie können diese auch jedes Mal neu kompilieren, indem sie Ausführungsstatistiken verwenden, die bei früheren Läufen gesammelt wurden, um Optimierungen zu steuern. Dies ermöglicht mehr Optimierungsaufwand für die Teile des Programms, die es am meisten benötigen. Dies wird adaptive Optimierung genannt.

Die CLR kompiliert alles nur einmal im Voraus. Es führt weniger Optimierungen durch, da es mehr Code zum Kompilieren hat und daher schnell sein muss und weil es keine Statistiken über die tatsächlichen Ausführungspfade enthält, die für die Optimierung verwendet werden. Dieser Ansatz bietet den entscheidenden Vorteil, dass Sie die Ergebnisse der Kompilierung zwischen den Prozessen zwischenspeichern können, was CLR, aber JVM nicht tut. Ein großer Prozentsatz des Hotspot-JVM-Codes ist diesen adaptiven Optimierungen gewidmet und sie haben Java in den frühen 2000er Jahren in die gleiche Performance wie nativer Code für die meisten allgemeinen Berechnungen gebracht. Sie machen die JVM auch zu einem ansprechenden Ziel für dynamische Sprachen. Ich schließe hier die neueren Entwicklungen der Dynamic Languages ​​Runtime aus und rege dynamisch an, da ich nicht genug über den DLR weiß.