Tag Archives: Heap

.NET Memory Internals – záznam a slides [Robert Haken, WUG Days Brno, 6.9.2024]

Záznam z přednášky pro konferenci WUG Days Brno z 6. září 2024, kde jsem ukazoval základy uspořádání paměti v .NET, internals Garbage Collectoru a pokročilý debugging pomocí Windows Debuggeru (WinDbg) a SOS extension.

Téma není zaměřené primárně na novinky, ale jde do hloubky — jak .NET skutečně spravuje paměť, jak to funguje uvnitř a jak se v tom vyznat při pokročilém debuggingu (Memory Dump, WinDbg, SOS).

Zásobník (Stack)

Zásobník je paměť pevné velikosti (defaultně 1 MB na thread), organizovaná pomocí Stack framů. Každé volání metody přidá Stack frame s lokálními proměnnými, parametry a návratovou adresou. Stack je základním mechanismem řízení běhu programu — bez něj by se metody neměly kam vracet. Stack overflow nastává téměř výhradně kvůli nekonečné rekurzi, ne proto, že by aplikace měla příliš hluboký call stack.

Managed Heap a Garbage Collector

.NET runtime si od Windows alokuje nativní paměť a část z ní předá Garbage Collectoru, který ji uspořádá jako managed heap. GC je zodpovědný nejen za uvolňování paměti (jak napovídá název), ale i za samotnou alokaci referenčních typů. Klíčovými koncepty jsou GC Generations (Gen0, Gen1, Gen2) pro generační sběr odpadu a Large Object Heap (LOH) pro velké objekty nad 85 000 bytů.

Windows Debugger (WinDbg) a Memory Dump

WinDbg je mocný, ale uživatelsky nepřívětivý nástroj pro analýzu .NET procesů a Memory Dumpů. Instaluje se přes Microsoft Store. Nejčastější workflow: z Task Manageru vytvoříte Memory Dump (pravé tlačítko → Create memory dump file), soubor načtete do WinDbg a analyzujete. Pro práci s .NET objekty je nezbytná SOS (Son of Strike) extension, která umožňuje zkoumat managed heap, zásobníky threadů a jednotlivé objekty přímo v paměti.

Slides

.NET [Core] Memory Internals – záznam, slides a dema [TechEd DevCon Praha 2019]

Záznam z přednášky pro konferenci TechEd DevCon Praha ze 16. května 2019.

Advanced Debugging .NET – záznam, slides a dema [ShowIT SK 02/2016]

Slides a dema z mé přednášky pro konferenci Gopas ShowIT Bratislava z 10.2.2016:

Záznam z přednášky je publikován na našem HAVIT YouTube Channel.

Dotčená témata

  • StackOverflow troubleshooting
  • Windows Debugger, SOS, DebugDiag
  • Prozkoumávání zásobníku
  • Prozkoumávání haldy, rootů, finalization queue
  • GC Root identification (static fields)

.NET Memory Internals – záznam, slides a dema [ShowIT SK 02/2016]

Slides a dema z mé přednášky pro konferenci Gopas ShowIT Bratislava z 9.2.2016:

Záznam z přednášky je publikován na našem HAVIT YouTube Channel.

Dotčená témata

  • Zásobník (Stack)
  • Hodnotové vs. referenční datové typy
  • Volání metod s předáváním parametrů hodnotou vs. referencí
  • Halda (Heap)
  • Garbage Collection

V případě zájmu o dané téma doporučuji shlédnou samostatné dvě přednášky, kde bylo o trochu více časového prostoru:

CLR Profiler, WinDbg a SOS při diagnostice memory-leaků

Problémem rychlého prozkoumávání velkých memory-dumpů v WinDbg/SOS je, že většinu zkoumání provádíme nad jednotlivými instancemi objektů. Vytipujeme si závadný typ (!dumpheap -stat) a pro pár instancí (!dumpheap -mt <MT>) zkoumáme, odkud pocházejí (!GCRoot <ObjAddr>). Pokud nemáme dost štěstí, po pár pokusech (které mohou být navíc při velkých memory-dumpech dosti časově náročné), nás to přestane bavit.

Nástrojem, jak provést v takovém případě hromadnou analýzu a pohlédnout na heap určitým agregovaným pohledem, je například CLR Profiler a jeho Heap Graph:

Ukazuje nám, jak na sebe jednotlivé typy navzájem referencují, a to vše v poměru k velikosti paměti (included, tedy včetně grafu referencovaných instancí). Vše je seskupeno po typech, nezabýváme se tedy jednotlivými instancemi.

Jak se k tomu dopracovat, mám-li memory dump

Z WinDbg/SOS je potřeba si vytvořit LOG-soubor pro CLR profiler pomocí příkazu

!TraverseHeap C:\output-path\name.log

…to samotné může nad velkým memory-dumpem hooodně trvat. Podle stroje a dumpu až hodiny. Na rozdíl od čekání na !GCRoot však dostanete výstup, který vás k cíli téměř jistě navede.

Následně již soubor načteme do CLR Profileru pomocí File / Open log file…

…zase čekáme a čekáme :-))

A na dialogu Summary for zvolíme Heap Graph

image

…čekáme a čekáme, až dostaneme třeba:

SNAGHTML96fdfd

Cache není nikdy dost ;-)

Mimochodem CLR Profiler nám dá i další zajímavé histogramy, které nám pomohou k pochopení poměrů v analyzovaném memory-dumpu. O nich možná někdy příště…

Viz též

.NET Memory Internals 2/2 – Heap, Garbage Collector – záznam, slides a dema [MS Fest Praha 2014]

Slides z mé přednášky 30.11.2014 pro konferenci MS Fest Praha:

Z přednášky jsem pořizoval záznam, který najdete na našem HAVIT YouTube Channelu:

.NET Internals 2/3 – Heap, Garbage Collector – záznam, slides a dema [TechEd Praha 2014]

Dema a slides z mé přednášky pro Gopas TechEd DevCon Praha 2014:

Druhá ze série přednášek:

Z přednášky jsem pořizoval záznam, který najdete na našem HAVIT YouTube Channelu: