Ich kenne also die Grundlagen hier - ein Objekt ist für Garbage Collection geeignet, wenn es nicht mehr von einem Root erreichbar ist (d. h. eine starke Referenz entweder von einer lokalen Variable in einem Stack-Frame oder eine statische Referenz)
Die Frage, die ich habe, ist diese potenzielle Optimierung, bei der, selbst wenn ein Objekt von einer lokalen Variablen referenziert wird, es zu irgendeinem Zeitpunkt in einer Funktion, in der die Variable nicht mehr referenziert wird, Müll gesammelt werden kann. Erstens - es scheint, dass existierende Implementierungen von C # dies nicht tun - sowohl 2.0 als auch 4.0 scheinen lokale Referenzen "live" zu halten, bis der Stapelrahmen zerstört ist. Aber - ich möchte auch Code schreiben, der immer noch robust ist, wenn die Garbage-Collection in späteren Versionen der CLR optimiert wird.
Also - ohne weitere Umschweife, hier ist ein Code-Illustration:
%Vor%Letztendlich scheinen die Regeln für bestehende CLRs wie folgt zu sein: 1. Jedes Objekt ist für die Dauer eines Funktionsaufrufs "live", für den es ein unmittelbares Argument ist 2. Jedes Objekt ist für die Dauer eines Funktionsaufrufs "live", wenn es durch eine lokale Stapelvariable referenziert wird, die nicht neu zugewiesen wird. (Auch wenn die Stapelvariable für mehrere Anweisungen am Ende der Funktion nicht referenziert werden kann)
Allerdings behält sich C # das Recht vor, (2) zu ändern, so dass ein Objekt bis zur endgültigen Verwendung einer Referenz innerhalb einer Funktion "live" ist.
Würde das bedeuten:
%Vor%Gibt es irgendetwas in der ECMA-Spezifikation, das sich mit der Berechtigung zur Garbage Collection im Detail befasst?
@ M.Babcock - Vielen Dank für den Link zur ECMA-Spezifikation! 8.4 war eigentlich zu allgemein, aber die Antwort, nach der ich suchte, war in 10.9 - und ist identisch mit Java - wenn eine Variable nicht mehr durch irgendeinen möglichen zukünftigen Codepfad referenziert werden kann, dann wird sie als geeignet für die Garbage Collection betrachtet - was bedeutet Obwohl die vorhandene clr-Implementierung die Lebensdauer der lokalen Variablen auf den Stack zu begrenzen scheint, gibt es keine Garantie dafür, dass Drittanbieter oder zukünftige Implementierungen dies tun.
Nun, es ist unmöglich, hier eine allgemeine Antwort zu geben, denn wann die Dinge tatsächlich für GC infrage kommen, hängt vollständig von der Implementierung Ihrer Laufzeit ab.
Das Einzige, dem Sie vertrauen können, sind die Garantien - das heißt, solange ein Objekt vom Stapel referenziert wird, wird es nicht gesammelt.
Sie können nicht an dem Code erkennen, wenn eine lokale Variable aus dem Stapel entfernt wird - dies ist anfällig für Compiler-Optimierungen - sowohl im statischen Compiler als auch im Jitter.
Was nun eine präzise Antwort sein mag, ist vielleicht nicht mehr nach dem nächsten kleinen Update Ihrer Runtime - es ist normalerweise am besten, Code zu schreiben, der nicht von solchen Feinheiten abhängt, was nur experimentell herausgefunden werden kann und stattdessen beruht nur für die Laufzeitgarantie.
Sie verweisen auf die Idee einer möglichen Optimierung, indem Sie ein Objekt früher sammeln.
Ich sehe das nicht als Optimierung.
Es ist nicht so, dass der Computer schneller oder besser läuft, wenn er mehr freien Speicher hat.
Entweder ist eine Zuweisung erfolgreich oder fehlgeschlagen.
Wenn es gelingt, läuft der Prozess gut.
Wenn dies fehlschlägt, befindet sich der Prozess in Schwierigkeiten.
(alles von trivial-trouble, von dem es sich erholen kann, bis zu deep-trouble, was zu einem Prozessabbruch führt)
Ich sehe einfach keinen Sinn darin, gegenüber G.C. aggressiver zu sein. wie du es beschreibst. Es würde nur in dem Grenzfall helfen, wo Sie bereits mit 99,99% des zugewiesenen Speichers laufen. Und in diesem Fall sind Sie tief in den virtuellen Speicher und paging auf die Festplatte auf eine verrückte Art und Weise.
Tags und Links c# garbage-collection