synopsis
/lmy5215006/p/18494483
In this article, while researching the underlying structure of .NET String, what I observed did not match the description in the book, "Getting Started with .NET Core Underpinnings", "The .NET Memory Management Dictionary". Therefore, I researched a bit more. NET Managed Heap structure is also found to be more and more high performance.
//sample code (computing)
internal class Program
{
public const string constStr = "";
static void Main(string[] args)
{
string name = "Lewis";
var person = ;
var str = constStr;
();
();
}
}
public class Person
{
public static string name = "liu";
}
Managed Heap Structure for .NET Core 3
Standard SOH (generation 0, generation 1, generation 2), LOH structure, so String Intern as a static content that can be determined during the JIT compilation phase, if placed in the SOH heap, it is not very suitable. Stored in the LOH heap instead is a better choice, because there is no generation up, no compression, and the memory address does not move in LOH. It is more suitable for static data.
Seeing is believing ---- heap structure
Seeing is believing whether ---- is assigned in LOH
-
Three memory addresses for static data
-
The root of their GC references
All three static data references the same gcroot -
GC root assignment at LOH
Managed Heap Structure for .NET 5
We can think about a problem, the definition of the LOH heap is the heap that only large objects of >=85000byte will enter. And static data just use the characteristics of LOH, but the essence of the LOH description does not match, belong to the speculative behavior. It also causes problems for developers, like me.
NET 5 onwards, the CLR developers added a Pinned object heap, a special heap for storing fixed objects. To solve the problem of mismatched definitions
Seeing is believing ----POH
Seeing is believing whether ---- is assigned at POH
Managed Heap Structure for .NET 8
By .NET 8, the CLR team added NonGC heap , which, as the name suggests, stands for a managed heap that doesn't get GC'd. Weird, right?
Then some people have questions? Isn't the POH heap already perfect? Why is there a need to add a new heap?The CLR team has the answer!
Mainly for performance, there are no write barriers and no GC. this greatly improves efficiency
/dotnet/runtime/blob/main/docs/design/features/
Seeing is believing ----NonGC heap
Seeing is believing---- whether it is allocated in NonGC Heap
reach a verdict
Therefore, when you refer to the books on the market, remember that knowing is believing and seeing is believing. Otherwise, it would be ridiculous to share outdated knowledge.