Wie können die Markierungs- und Sweep-Phasen von .NET GC gleichzeitig mit Anwendungsthreads ausgeführt werden?Wie können die Markierungs- und Sweep-Phasen von .NET GC gleichzeitig mit Anwendungsthreads ausgeführt werden?
Dies ist nur eine begründete Vermutung, die genauen Details des Kollektors sind nirgendwo verfügbar. Die freigegebene Quellversion der CLR verfügt nicht über die Goodies.
Wie bereits erwähnt, findet eine gleichzeitige Sammlung nur während der Gen # 2-Sammlung statt, die eine Stichprobe bilden kann, da es keine vernünftige Obergrenze für die Anzahl der Objekte in dieser Generation gibt. Und kann die Reaktionsfähigkeit einer GUI-App auf einer Workstation sichtbar beeinflussen. Gen # 0 und # 1 sind bereits gesammelt und hinterlassen einen ordentlichen Teil des zu reservierenden Speichers. Es kann den Graph von Objekten der 2.Generation, die beim Sammeln von 0 und 1 gefunden wurden, gestartet haben.
Ich denke, dass der GC zuerst alle Threads aussetzt, damit es ihre Stack- und CPU-Register sicher durchlaufen kann, um Objektreferenzen zu finden. Das kann ziemlich schnell passieren. Und fügt sie dem Diagramm hinzu.
Es kann jetzt die Threads freigeben, sie können weiterlaufen, ohne befürchten zu müssen, dass Objektverweise ungültig werden, weil noch nichts bewegt wird. Zuteilungen aus Gen # 0 sind kein Problem, vielleicht kann es sogar # 0 sammeln, wenn es voll ist. Der Blogpost schlägt vor, dass es tut.
In der Zwischenzeit kann der Kollektor Gen # 2 gehen und Referenzen zu den Graphen von den Objekten hinzufügen. Und herausfinden, welche Objekte nicht mehr referenziert werden. Währenddessen laufen Threads. Wenn die unteren Generationen nicht voll sind, dann läuft ein Thread, der zuordnet, in eine Sperre.
Als nächstes müssen die Threads erneut angehalten werden, damit sie gen # 2 komprimieren, Objekte verschieben und ihre Referenzen aktualisieren können. Die Zeit, die benötigt wird, ist ziemlich unberechenbar. Ich habe keinen Einblick, ob es ein Gigabyte von Objekten verschieben wird, um ein Loch von 16 Bytes zu füllen, die früh im Heap frei geworden sind. Ich bezweifle ernsthaft, dass das 200 ms dauert.
Eine Konsequenz dieser Theorie ist, dass sie keine gen # 2 Objekte freigibt, die nicht referenziert wurden, während die Threads während der Sammlung liefen. Das könnte eine Möglichkeit sein, diese Theorie zu testen, obwohl ich nicht wirklich einen guten Weg sehe, dies zu tun.
Ich bin mir nicht sicher, ob es so ist. Laut Maoni Stephens blog.
Während eines gleichzeitige GC wir verwalteten Threads zweimal zu tun, einige Phasen des GC suspendieren müssen.
Sie schreibt diese Phasen nicht.
Auch aus dem Eintrag
Concurrent GC, auf der anderen Seite läuft gleichzeitig mit dem verwalteten Threads auf Folgendes erstrecken:
§ Es Ihnen, während eine gleichzeitige GC zuzuordnen erlaubt ist in Bearbeitung.
Sie können jedoch nur so viel vergeben - für kleine Objekte Sie höchstens bis zu Ende das kurzlebige Segment zuordnen kann. Denken Sie daran, wenn wir keine kurzlebige GC tun, die Gesamt Raum von ephemeren Generationen besetzt kann so groß sein, wie ein voll Segment ermöglicht so, sobald Sie das Ende des Segments erreicht man benötigen, warten die gleichzeitige GC zu beenden, so verwaltet, Threads, die müssen kleine Objektzuweisungen sind ausgesetzt werden.
§ Es muss die verwalteten Threads während eines gleichzeitigen GC noch einige Male stoppen.
Während einer gleichzeitige GC müssen wir verwaltete Threads zweimal unterbrechen, um einige Phasen des GC zu tun. Diese Phasen könnten möglicherweise eine Weile dauern, um zu beenden. Wir nur gleichzeitige GCs für vollständige GCs. Ein Voll-GC kann entweder ein gleichzeitiger GC oder ein blockierender GC sein. Ephemere GCs (dh gen0 oder gen1 GCs) blockieren immer. Concurrent GC ist nur für Workstation GC verfügbar. In Server GC wir immer blockieren GCs für alle GCs.
Sie könnten auch interessiert sein an this video.