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.
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
@@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.
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
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?
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 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.
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.
thank you for sharing
Just bought without second thought. I am sure that there is great content inside.
Thank you Anton
thank you, I really appreciate it!
Always great videos, Anton! I appreciate the level of details you go into your explanations. Hard to find it on the web.
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
Helpful
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.
@@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 And is the content still relevant when it comes to coreCLR ?
More content like this, thanks. Tired of newbie shit all over the place
aye aye chief
@@RawCoding thx a lot :)
thank you@@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
Make your code readable and compressible
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?
it is not so common to run over 85k in webapi world
probably there is an edge case where you use array of struct so the tipping point will be 85k/sizeof(myStruct) - 3
Appreciate your effort.
I think it's better if you can share reference source
you can get the source code if you support me on patreon.
Thank you
Doesn't the unmanaged memory go away if you click the legend? That would make visualization better
don't know
@@RawCoding can you make video about what is garbage collector and how works?
oh, nice!
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.
What do you mean how you know? That’s how it’s built. LOH is inside gen 2
@@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.
Yes you are right, physically LOH is a separate memory boundary from gen2 memory region. Both are collected as part of gen 2 gc
my g stopped using console apps for demos and replaced them with minimal APIs
minimal apis are console apps with extra steps :D
When you gc gen 1, gc is made in gen 0 and when gc runs gen2 gc is also made in 1 & 0
FORST!!!! 💋💋💋