Gibt es einen verwalteten Heap pro CLR oder pro Prozess?

Question

Soweit ich weiß, vor .NET 4.0 Dinge einfach waren: ein Prozess konnte nur einen Host CLR.

Aber ab Version 4.0 kann ein Prozess mehr als eine CLR hosten.

In diesem Fall, denke ich, gibt es einen Haufen pro CLR, weil jede CLR seinen eigenen Zustand und seine eigene GC mit seiner eigenen Art der Verwaltung von Speicher und seine eigenen Sammlungszyklen hat, so Speicher zu teilen scheint einfach unmöglich.

1) Können Sie bestätigen, dass dies eindeutig der Fall ist oder ist es subtiler?

2) Sind zwei CLRs im selben Prozess gehostet, streng isoliert oder können sie etwas teilen? (vor allem, wenn sie die gleiche Version haben, könnten sie einander kennen)

Ich denke, die Antworten sind ja und ja (isoliert), aber ich möchte sicher sein.

Danke für jede Einsicht.

Answer 1

Das erste, was wir brauchen - ist zu klären, oder eine Karte, was in einem allgemeinen geschieht:

Sie Ihre EXE-Datei ausführen -> die Datei für einen .NET-CLR fragt -> die CLR-Prozess - Gastgeber Ihre Ausführung.

so kurz sein, ich es kürzer ziehen werde:

Dies ist, was in den vergangenen 4,0 vorging:
File1.exe Ausführen -> CLR Prozess -> Hosts (.net File1. exe) => hier gehe ich davon aus file1.exe ist .net1
Execute File2.exe -> CLR Process2 -> hosts (.net File2.exe) => hier gehe ich davon aus file2.exe ist .net2
Datei3.exe ausführen -> CLR Process3 -> hosts (.net File3.exe) => hier gehe ich davon aus, dass file3.exe ist .net3

In der abov Bei den Beispielen gehe ich davon aus, dass .net 3 auf der Maschine installiert ist, und deshalb ist .net3 CLR der Prozess - und richtig - 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 werden 3 verschiedene Befehlszeiger verwendet und jeder Prozess hat seinen eigenen getrennten Haufen.

Und das ist, was mit 4,0 geschieht und 4,5:
File4.exe Ausführen -> CLR Process45 -> Gastgeber (.net File4.exe) => hier gehe ich davon aus file4.exe ist .net4
Execute file45.exe ->CLR Process45 -> beherbergt auch (.net File45) => hier ich gehe davon aus file45.exe .net4.5

In den obigen Beispielen ist gehe ich davon aus .net 45 auf dem Computer installiert ist , also .net CLR4 ist der Prozess, der nur einmal geladen wurde (und nicht zweimal! wie von der Logik der vorherigen Beispiele erwartet)

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 von mehr Relevanz, was Sie genau fragen:
Jeder Prozess hat einen einzigen Heap - das kann nicht geändert werden, wie es die Hardware funktioniert.
(unabhängig davon, was CLR, das ist nur ein anderer Prozess in diesem Sinne tun kann)
Aber um in der Lage zu sein, einen Heap pro exe gehostet zu bieten, erfanden sie ein Konzept namens "Blob-Heap", die in den Haufen gelegt wird der CLR-Prozess. So viele Blob Heaps können auf einmal 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 einzelne 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 ein solches potenzielles Problem in der Architektur gelöst wird.

ich aus all diesen Quellen lesen Sie diese Antwort zu montieren:
Common Language Runtime (CLR)
ECMA C# and Common Language Infrastructure Standards
Common Language Infrastructure (CLI) Partitions I to VI (6th edition)
In-Process Side-by-Side
Loading multiple CLR Runtimes (InProc SxS) – Sample Code