Soweit ich weiß, waren die .NET 4.0 Dinge einfach: Ein Prozess konnte nur eine CLR hosten.
Aber ab Version 4.0 kann ein Prozess mehr als eine CLR hosten.
In diesem Fall, denke ich, gibt es einen Heap pro CLR , da jede CLR ihren eigenen Status und ihren eigenen GC mit einer eigenen Methode zur Verwaltung von Speicher und eigenen Erfassungszyklen hat scheint einfach unmöglich.
1) Können Sie bestätigen, dass dies schlüssig der Fall ist oder ist es subtiler?
2) Sind zwei CLRs im selben Prozess isoliert oder können sie etwas teilen? (Besonders wenn sie die gleiche Version haben, könnten sie sich gegenseitig kennen)
Ich denke, die Antworten sind ja und ja (isoliert), aber ich bin mir sicher.
Danke für jede Einsicht.
Das erste, was wir brauchen, ist das Aussortieren oder Abbilden, was in einem allgemeinen geschieht:
Sie führen Ihre exe-Datei aus - & gt; Die Datei fragt nach einer .NET CLR - & gt; der CLR-Prozess - hostet Ihre Ausführung.
Um es kurz zu machen, ich werde es kürzer zeichnen:
Dies ist, was vor 4.0 passierte:
Führen Sie File1.exe aus - & gt; CLR-Prozess - & gt; Hosts (.net File1.exe) = & gt; Hier nehme ich an, dass file1.exe .net1 ist
Führen Sie File2.exe aus - & gt; CLR-Prozess2 - & gt; Hosts (.net File2.exe) = & gt; hier nehme ich an, dass file2.exe ist .net2
Führen Sie File3.exe aus - & gt; CLR-Prozess3 - & gt; hosts (.net File3.exe) = & gt; hier gehe ich davon aus, dass file3.exe .net3
In den obigen Beispielen gehe ich davon aus, dass .net 3 auf der Maschine installiert ist, und deshalb ist .net3 CLR der Prozess - und wahr - es wurde 3 Mal geladen! Da die DLL jedoch die gleiche DLL ist, können Windows-Fenster sie teilen, so als wäre sie nur einmal geladen worden. aber im Speicher - 3 verschiedene Befehlszeiger werden darauf verwendet und jeder Prozess hat seinen eigenen getrennten Haufen.
Und das passiert mit 4.0 und 4.5:
Führen Sie File4.exe aus - & gt; CLR-Prozess45 - & gt; hosts (.net File4.exe) = & gt; hier gehe ich davon aus, dass file4.exe .net4 ist
Führen Sie File45.exe aus - & gt; CLR-Prozess45 - & gt; auch Hosts (.net File45) = & gt; hier nehme ich an, dass file45.exe .net4.5
In den obigen Beispielen gehe ich davon aus, dass .net 45 auf der Maschine installiert ist, also .net CLR4 ist der Prozess, der nur einmal (und nicht zweimal!) geladen wurde, wie es von der Logik vorheriger Beispiele erwartet wurde.
Sie können mehr in den Links lesen, die ich am Ende meiner Antwort zur Verfügung stelle, um zu erfahren, welche Versionen zusammen "sitzen" können - nicht alle Version kann Seite an Seite mit allen Versionen sitzen.
Der zweite Teil meiner Antwort ist relevanter für das, was Sie genau fragen:
Jeder Prozess hat einen einzelnen Heap - das kann nicht geändert werden, da die Hardware so funktioniert.
(unabhängig davon, was CLR ist, was nur ein anderer Prozess in diesem Sinne ist)
Um jedoch einen Heap pro exe bereitstellen zu können, haben sie ein Konzept namens "blob-heap" erfunden, das in den Heap des CLR-Prozesses gestellt wird. So viele Blob Heaps können sofort verwaltet werden.
Jede gehostete App in der CLR hat einen eigenen GC und sie sind isoliert und kennen sich nicht gegenseitig.
Nach meinem Verständnis wird in .NET4 nur eine einzige CLR verwendet, die viele Host-Elemente oder Apps verwalten kann. Dies bedeutet, dass sich viele Apps gegenseitig in ihrem Potenzial bremsen, aber das gilt auch, wenn stattdessen der "Multi-CLR" -Ansatz verwendet wird. Das akutere Problem ist, dass wenn CLR selbst nicht mehr läuft, alle gehosteten Apps nicht mehr laufen es. Ich habe keine Ahnung, wie oder ob dieses potenzielle Problem in der Architektur gelöst wird.
Ich habe von all diesen Quellen gelesen, um diese Antwort zu sammeln:
Common Language Runtime (CLR)
ECMA C # und Common Language Infrastructure Standards
Gemeinsame Sprachinfrastruktur (CLI) Partitionen I bis VI (6. Ausgabe)
In-Prozess Seite-an-Seite
Laden mehrerer CLR-Laufzeiten (InProc SxS) - Beispiel Code