KZhead

Understanding .NET C# Heaps (Deep Dive)

Raw Coding
2024 ж. 12 Мам.
11 703 Рет қаралды
Жүктеу

A deep dive in to the .net heap structure, understanding heap generations, where objects are allocated in the heap, how objects move across generations and how to leverage this information to your advantage.
Patreon 🤝 / raw_coding
Courses 📚 learning.raw-coding.dev
Shop 🛒 shop.raw-coding.dev
Discord 💬 / discord
Twitter 📣 / anton_t0shik
Twitch 🎥 / raw_coding
🕰 Timestamps
00:00 Introduction
00:50 heap visualisation
08:18 moving objects between generations
13:48 allocating / promoting / sweeping / compacting
17:45 objects array tipping point
20:20 list array tipping point
24:40 performance metrics
27:53 the end
#dotnet #csharp #heap

Пікірлер

  • In case anyone wonders why 85,000 was used in the example - from Microsoft docs -> If an object is greater than or equal to 85,000 bytes in size, it's considered a large object. This number was determined by performance tuning. When an object allocation request is for 85,000 or more bytes, the runtime allocates it on the large object heap.

    @dwhxyz@dwhxyz Жыл бұрын

    • thank you for sharing

      @RawCoding@RawCoding Жыл бұрын

  • It is worth mentioning, that as J.Richter mentioned in his book "CLR via C#", during GC, objects with deconstructors (finalizers), which no longer have references are placed in a Freachable queue. A special CLR high-priority thread picks up objects from that queue, runs Finalize method (deconstructor), after what marks objects as ready for collection. Next time GC checks for objects from the Freachable queue which were marked as ready for collection and cleans them up. That's why the developer cannot be sure when an object with a deconstructor will be garbage-collected during the next GC

    @m-xeas@m-xeas Жыл бұрын

    • Helpful

      @mrwalkan@mrwalkan Жыл бұрын

    • Do you recommend the book? Up til now I avoided reading it but it comes coming up in my career everytime I search for internals.

      @codewkarim@codewkarim Жыл бұрын

    • @@codewkarimI bet you wouldn't regret reading it. The main advantage of this book is that Richter explains CLR using C# as an example, so you will find a lot of "under the hood" stuff.

      @m-xeas@m-xeas Жыл бұрын

    • @@m-xeas And is the content still relevant when it comes to coreCLR ?

      @codewkarim@codewkarim Жыл бұрын

  • Always great videos, Anton! I appreciate the level of details you go into your explanations. Hard to find it on the web.

    @marcellusfarias5480@marcellusfarias54803 ай бұрын

  • Just bought without second thought. I am sure that there is great content inside. Thank you Anton

    @MrJonnis13@MrJonnis13 Жыл бұрын

    • thank you, I really appreciate it!

      @RawCoding@RawCoding Жыл бұрын

  • ok I was sleepy when I watched the vid, but my question is what should we do besides reducing the number of allocations in the code ? what technique we should follow? thanks Anton your vids are always grate

    @TheNorthRemember@TheNorthRemember3 ай бұрын

    • Make your code readable and compressible

      @RawCoding@RawCoding3 ай бұрын

  • More content like this, thanks. Tired of newbie shit all over the place

    @s0weer@s0weer Жыл бұрын

    • aye aye chief

      @RawCoding@RawCoding Жыл бұрын

    • @@RawCoding thx a lot :)

      @s0weer@s0weer Жыл бұрын

    • thank you@@RawCoding

      @TheNorthRemember@TheNorthRemember3 ай бұрын

  • probably there is an edge case where you use array of struct so the tipping point will be 85k/sizeof(myStruct) - 3

    @adrian_franczak@adrian_franczak Жыл бұрын

  • It's a very good content nice topic 🤩 .Can we have part 2 related/similar to avoiding object greater than 85 kilo bytes. How to deal with those large LOH object if occured in any scenario?

    @bakbak_babble@bakbak_babble Жыл бұрын

    • it is not so common to run over 85k in webapi world

      @adrian_franczak@adrian_franczak Жыл бұрын

  • Thank you

    @ivandrofly@ivandrofly Жыл бұрын

  • oh, nice!

    @sergeys5270@sergeys5270 Жыл бұрын

  • Appreciate your effort. I think it's better if you can share reference source

    @minhnguyenkha867@minhnguyenkha867 Жыл бұрын

    • you can get the source code if you support me on patreon.

      @RawCoding@RawCoding Жыл бұрын

  • Doesn't the unmanaged memory go away if you click the legend? That would make visualization better

    @danspark@danspark Жыл бұрын

    • don't know

      @RawCoding@RawCoding Жыл бұрын

    • @@RawCoding can you make video about what is garbage collector and how works?

      @RoyZASTEROiD@RoyZASTEROiD Жыл бұрын

  • my g stopped using console apps for demos and replaced them with minimal APIs

    @ManderO9@ManderO9 Жыл бұрын

    • minimal apis are console apps with extra steps :D

      @RawCoding@RawCoding Жыл бұрын

  • When you gc gen 1, gc is made in gen 0 and when gc runs gen2 gc is also made in 1 & 0

    @pedroferreira9234@pedroferreira9234 Жыл бұрын

  • how i know only SOH is seperated to generations, LOH is not seperated to any generation. And how i know - yes, when gen 2 is collected by GC, same time automatically LOH will too collected by GC.

    @RoyZASTEROiD@RoyZASTEROiD11 ай бұрын

    • What do you mean how you know? That’s how it’s built. LOH is inside gen 2

      @RawCoding@RawCoding11 ай бұрын

    • @@RawCoding how i know = how i read before. Loh is separated segment from gen2, loh internally kept tracked as gen3. But there are collected at the same time when gen2 is collected by gc. I mean saying that gen2 is seperated to 2 parts loh/soh is not fully truth. There are collected at the same time (when gc was called for gen2) yes, but this not means soh and loh are stored in gen2 or part of gen2.

      @RoyZASTEROiD@RoyZASTEROiD11 ай бұрын

    • Yes you are right, physically LOH is a separate memory boundary from gen2 memory region. Both are collected as part of gen 2 gc

      @RawCoding@RawCoding11 ай бұрын

  • FORST!!!! 💋💋💋

    @nunyabuziness2700@nunyabuziness2700 Жыл бұрын
KZhead