Garbage Collection und native Referenz
-
Hallo zusammen,
ich habe als C++/CLI Neuling eine allgemeine Frage zur Strategie des Garbage Collectors (GC).
Die Häufigkeit und Dauer einer Garbage Collection wird u.a. durch den Umfang der Speicherbelegung bestimmt. Übersteigt die Speicherbelegung auf dem verwalteten Heap einen Schwellwert, so stößt dies ggfs. den GC an. Der GC verwaltet außerdem separate Heaps für große (min. 85.000 Bytes) und kleine Objekte und kann daher große und kleine Objekte unterschiedlich behandeln.
Angenommen ein verwaltetes kleines Objekt hält eine Referenz auf ein sehr großes natives Objekt. Ein Dispose durch einen deterministischen Destruktor soll vermieden werden. Daher wird das native Objekt erst im Finalizer des verwalteten Objektes (also durch den GC) wieder freigegeben.
Wirkt sich das nicht nachteilig auf die GC-Strategie aus? Der GC weiß schließlich nicht, dass im Hintergrund des kleinen verwalteten Objektes ein äußerst speicherintensives natives Objekt lebt. Gibt es einen Weg, dieses dem GC mitzuteilen (Priorität des verwalteten Objektes verändern o.ä.)? Ich möchte wie gesagt nach Möglichkeit auf einen determisitischen Destruktor verzichten.
VG
-- oXmoX
-
Da der native SPeicher ja ganz woanders liegt ist dem GC das ja wurscht... warum sollte er es wissen (müssen)?
Der LOH gibt es ja nur, damit er nicht immer großen Speicher allokieren freigeben muss.Mit Deinem native Speicher hat dies nichts zu tun...
Das einzige was den GC im allgemeinen interessieren könnte, wäre zu wissen, ob Du noch sehr viel native Speicher zusätzlich zu den managed Objekten verwendest. Dies kann den GC beeinflussen selber nicht so viel Speicher zu verwenden. Da bist Du dann aber in den tiefen des GC drin und solltest schon genau wissen, was Du tust...
Siehe dazu: System::GC::AddMemoryPressure/RemoveMemoryPressure
http://msdn.microsoft.com/en-us/library/system.gc.addmemorypressure.aspx
http://msdn.microsoft.com/en-us/library/system.gc.removememorypressure.aspx
-
Treffer! Deine Links sind genau das, was ich gesucht habe. Danke!
-
Bei näherer Betrachtung habe ich noch eine Frage in diesem Zusammenhang.
Angenommen ich habe ein sehr speicherintensives und ein sehr speicherarmes Objekt (beide managed und gleiche Generation), die jeweils auf die Finalisierung durch den GC warten. Stimmt es, dass der GC nun das größere Objekt mit höherer Priorität wieder freigibt?
-
Der LOH hat keine "Generation". Die gibt es nur im normalen Heap...
In .NET 4 wurden da aber einige Optimierungen eingeführt. Vor allem auch das freigeben des LOHs, was es bisher nicht gab
-
Jochen Kalmbach schrieb:
Der LOH hat keine "Generation". Die gibt es nur im normalen Heap...
Okay, dann vergiss das mit den Generationen wieder. Wichtig ist eigentlich nur, dass sie gleich alt sind und zur selben Zeit für die Garbage Collection freigegeben werden.
Meine Frage ist eigentlich, ob die Größe eines Objektes auf dem managed Heap das GC-Scheduling beinflusst. Also, ob kleine Objekte im Schnitt auch länger auf den GC warten müssen.
-
So kann man das nicht sagen... man kann eigentlich gar keine AUskunft darüber geben, wann ein Objekt freigegeben wird.. unabhängig von der Größe...
-
Jochen Kalmbach schrieb:
unabhängig von der Größe...
Doch, ich glaube schon, dass die Größe einen wichtigen Einfluss nimmt. Aus der Generationsperspektive gesehen, gehören große Objekte zur Generation 2, da sie nur bereinigt werden, wenn eine Garbage Collection für die Generation 2 stattfindet. Ein kleines Objekt startet dagegen immer in der Generation 0. Eine Garbage Collection für die Generation 0 wird häufiger ausgeführt als für die Generationen 1 und Generation 2 wird noch seltener bereinigt. Somit würde ich annehmen, dass die Wahrscheinlichkeit für eine schnelle Freigabe bei kleinen Objekten etwas höher ist.
-
Große Objekte landen im LOH... da gibt es keine Generationen... man könnte es mit der G2 vergleichen..
SIehe auch (aber wirst Du vermutlich schon kennen):
http://msdn.microsoft.com/en-us/magazine/cc534993.aspx