Warum Large Object Heap und warum kümmert es uns?
Habe ich gelesen, die über Generationen und Large object heap. Aber ich verstehe immer noch nicht, welche Bedeutung (oder profitieren) having Large object heap?
Was könnte falsch gelaufen ist (in Bezug auf Leistung oder Arbeitsspeicher), wenn die CLR-hätte nur auf Sie berufen, Generation 2 (wenn man Bedenkt, dass die Schwelle für die Gen0 und Gen1 ist klein, um die Bearbeitung Großer Objekte) für die Speicherung großer Objekte?
InformationsquelleAutor der Frage Manish Basantani | 2012-01-21
Du musst angemeldet sein, um einen Kommentar abzugeben.
Einer garbage collection nicht nur loszuwerden, der nicht referenzierte Objekte, es auch komprimiert heap. Das ist eine sehr wichtige Optimierung. Es nicht nur die Speichernutzung effizienter (keine ungenutzten Löcher), macht es die CPU-cache-viel effizienter. Der cache ist eine wirklich große Sache über moderne Prozessoren, Sie sind einfach um ein Vielfaches schneller als der Speicher-bus.
Verdichtung erfolgt einfach durch das kopieren von bytes. Das aber braucht Zeit. Je größer das Objekt, desto wahrscheinlicher ist, dass die Kosten für das kopieren, es überwiegt die möglichen CPU-cache-Auslastung Verbesserungen.
So liefen Sie eine Reihe von benchmarks, um zu bestimmen, die break-even-point. Und kam auf 85.000 bytes als die cutoff-Punkt, wo das kopieren nicht mehr verbessert perf. Mit einer speziellen Ausnahme für arrays von zwei, Sie sind als 'large' wenn das array mehr als 1000 Elemente. Das ist eine weitere Optimierung für 32-bit-code, der large object heap allocator hat die Besondere Eigenschaft, dass es reserviert Speicher auf Adressen ausgerichtet werden, um 8, im Gegensatz zu den regulären Generationen-Zuweisung, nur reserviert ausgerichtet 4. Das alignment ist eine große Sache für Doppel -, Lesen oder schreiben eines mis-aligned double ist sehr teuer. Seltsam das spärliche Microsoft info nie erwähnen arrays von langen, nicht sicher, was es damit auf sich.
Fwiw, es gibt viele Programmierer angst um die large object heap nicht immer komprimiert. Dieser unweigerlich ausgelöst wird, wenn Sie Programme schreiben, die verbrauchen mehr als der Hälfte der gesamten verfügbaren Adressraum. Gefolgt von mit einem Werkzeug, das wie ein memory profiler, um herauszufinden, warum das Programm bombardiert, obwohl es noch viele freie virtueller Speicher zur Verfügung steht. Ein solches tool zeigt die Löcher in der LOH, ungenutzte Speicherbereiche, wo zuvor ein großes Objekt gelebt aber habe Müll gesammelt. Eine solche ist das unvermeidliche Preis des LOH, das Loch kann nur wieder verwendet werden, indem eine Zuweisung für ein Objekt, das gleich oder kleiner in der Größe. Das eigentliche problem ist die Annahme, dass ein Programm sollte erlaubt werden, zu konsumieren alle virtuellen Speicher zu jeder Zeit.
Problem, sonst verschwindet vollständig, indem Sie nur die Ausführung des Codes auf einem 64-bit-Betriebssystem. Ein 64-bit-Prozess hat 8 Terabyte virtueller Adressraum zur Verfügung, 3 Größenordnungen mehr ist als ein 32-bit-Prozess. Sie können nicht gerade aus laufen Löcher.
Lange Geschichte kurz, die LOH code macht, laufen effizienter. Auf Kosten der Verwendung von verfügbaren virtuellen Adressraum im Speicher weniger effizient.
UPDATE .NET 4.5.1 unterstützt jetzt komprimieren der LOH, GCSettings.LargeObjectHeapCompactionMode Eigenschaft. Hüten Sie sich vor den Konsequenzen, bitte.
InformationsquelleAutor der Antwort Hans Passant
Wenn das Objekt größer ist als einige angeheftete Wert (85000 Byte .NET-1), dann die CLR stellt es im Large Object Heap. Dies optimiert:
nieselten verdichtet)InformationsquelleAutor der Antwort oleksii
Der wesentliche Unterschied von Small Object Heap (SOH) und Large Object Heap (LOH), - Speicher in der SOH wird verdichtet, wenn gesammelt, während LOH nicht, wie dieser Artikel veranschaulicht. Komprimieren große Objekte, die viel Kosten. Ähnlich wie mit den Beispielen in dem Artikel, sagen wir verschieben ein byte im Speicher benötigt 2 Zyklen, dann komprimieren einer 8MB-Objekt in ein 2 GHz Rechner braucht 8ms, das ist ein großer Aufwand. Die Berücksichtigung großer Objekte (arrays in den meisten Fällen) sind durchaus üblich in der Praxis, ich nehme an das ist der Grund, warum Microsoft pins, große Objekte in den Speicher und schlägt LOH.
BTW, nach dieser BeitragLOH in der Regel nicht generieren, memory fragment-Probleme.
InformationsquelleAutor der Antwort grapeot
Den AUFTRAGGEBER ist, dass es unwahrscheinlich (und sehr wahrscheinlich schlechtes design), dass ein Prozess schaffen würde, viele der kurzlebigen große Objekte, so dass die CLR reserviert große Objekte auf einen separaten Haufen, auf dem er läuft GC auf einen anderen Zeitplan für die regelmäßige heap. http://msdn.microsoft.com/en-us/magazine/cc534993.aspx
InformationsquelleAutor der Antwort Myles McDonnell
Ich bin kein Experte auf der CLR, aber ich könnte mir vorstellen, dass mit einer dedizierten heap für große Objekte kann verhindern, dass unnötige GC fegt der bestehenden Generationen-Haufen. Die Zuweisung eines großen Objekts erfordert eine erhebliche Menge an zusammenhängenden freien Speicher. Um dafür zu sorgen, dass aus den verstreuten "Löcher" in der Generationen-Haufen, Sie müssten Häufig Komprimierungen (die sind nur fertig mit GC-Zyklen).
InformationsquelleAutor der Antwort Chris Shain