Understanding .NET C# Heaps (Deep Dive)

Поділитися
Вставка
  • Опубліковано 31 тра 2024
  • 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

КОМЕНТАРІ • 36

  • @dwhxyz
    @dwhxyz Рік тому +18

    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.

  • @s0weer
    @s0weer Рік тому +10

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

  • @m-xeas
    @m-xeas Рік тому +5

    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

    • @mrwalkan
      @mrwalkan Рік тому

      Helpful

    • @codewkarim
      @codewkarim Рік тому

      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.

    • @m-xeas
      @m-xeas Рік тому +1

      @@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.

    • @codewkarim
      @codewkarim Рік тому +1

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

  • @MrJonnis13
    @MrJonnis13 Рік тому +3

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

    • @RawCoding
      @RawCoding  Рік тому +1

      thank you, I really appreciate it!

  • @marcellusfarias5480
    @marcellusfarias5480 4 місяці тому

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

  • @TheNorthRemember
    @TheNorthRemember 3 місяці тому +1

    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

    • @RawCoding
      @RawCoding  3 місяці тому

      Make your code readable and compressible

  • @bakbak_babble
    @bakbak_babble Рік тому +4

    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?

    • @adrian_franczak
      @adrian_franczak Рік тому

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

  • @ivandrofly
    @ivandrofly Рік тому

    Thank you

  • @adrian_franczak
    @adrian_franczak Рік тому

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

  • @sergeys5270
    @sergeys5270 Рік тому

    oh, nice!

  • @minhnguyenkha867
    @minhnguyenkha867 Рік тому +3

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

    • @RawCoding
      @RawCoding  Рік тому +1

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

  • @danspark
    @danspark Рік тому +1

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

    • @RawCoding
      @RawCoding  Рік тому

      don't know

    • @RoyZASTEROiD
      @RoyZASTEROiD Рік тому +1

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

  • @ManderO9
    @ManderO9 Рік тому +1

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

    • @RawCoding
      @RawCoding  Рік тому +4

      minimal apis are console apps with extra steps :D

  • @pedroferreira9234
    @pedroferreira9234 Рік тому

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

  • @RoyZASTEROiD
    @RoyZASTEROiD Рік тому +1

    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.

    • @RawCoding
      @RawCoding  Рік тому

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

    • @RoyZASTEROiD
      @RoyZASTEROiD Рік тому +1

      @@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.

    • @RawCoding
      @RawCoding  Рік тому

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

  • @nunyabuziness2700
    @nunyabuziness2700 Рік тому

    FORST!!!! 💋💋💋