Introduction
Managed memory in .Net is separated on “Stack” memory and some kind of “heaps”. The most important types of “heaps” is SOH (Small Object Heap) and LOH(Large Object Heap). From the names of memory types becomes clear that SOH - stores only small objects & LOH stores large objects. In this article I will consider only possible problem with LOH memory. Other memory types are out of scope of this article.
LOH
How the CLR decides which objects must be stored in LOH and with objects must be stored in SOH? Unfortunately I didn’t find an exact answer on this question, but my own experiments and investigation shows that object is created in LOH when object size is more than 80000 bytes. Possibly Microsoft decided to use this size of memory, because the tests show balance between performance and memory usage, but it’s question to guys from Microsoft. Size of memory you can get programmatically or you can use some tools for this, “Process Explorer” for example.
Some LOH features and problems associated with these features
Objects in LOH cannot be moved, it means that memory becomes fragmented and calls to memory become slower.
LOH memory only increases and never decreases, even if GC finished collect garbage. It means that in some wonderful moment you can get “OutOfMemoryException”. This problem is particularly actual in x86 machines where memory is limited only with 3 GB for each process.
Such problems can occur only if you use large collections of structures. It’s not a good practice to create a lot of structures, but what can we do if we already have large arrays with million records and all these records is value type? For the beginning we can try to replace all keywords from ‘struct’ to ‘class’ in our solution, for most types of applications it can solve problem, but we will get another one: a lot of NullReferenceExcceptions will haunt us throughout our solution. My solution for this problem is simple: we can use paged array(array of arrays) instead of simple, one dimensional array.
LargeList implementation
Read more: Codeproject
Managed memory in .Net is separated on “Stack” memory and some kind of “heaps”. The most important types of “heaps” is SOH (Small Object Heap) and LOH(Large Object Heap). From the names of memory types becomes clear that SOH - stores only small objects & LOH stores large objects. In this article I will consider only possible problem with LOH memory. Other memory types are out of scope of this article.
LOH
How the CLR decides which objects must be stored in LOH and with objects must be stored in SOH? Unfortunately I didn’t find an exact answer on this question, but my own experiments and investigation shows that object is created in LOH when object size is more than 80000 bytes. Possibly Microsoft decided to use this size of memory, because the tests show balance between performance and memory usage, but it’s question to guys from Microsoft. Size of memory you can get programmatically or you can use some tools for this, “Process Explorer” for example.
Some LOH features and problems associated with these features
Objects in LOH cannot be moved, it means that memory becomes fragmented and calls to memory become slower.
LOH memory only increases and never decreases, even if GC finished collect garbage. It means that in some wonderful moment you can get “OutOfMemoryException”. This problem is particularly actual in x86 machines where memory is limited only with 3 GB for each process.
Such problems can occur only if you use large collections of structures. It’s not a good practice to create a lot of structures, but what can we do if we already have large arrays with million records and all these records is value type? For the beginning we can try to replace all keywords from ‘struct’ to ‘class’ in our solution, for most types of applications it can solve problem, but we will get another one: a lot of NullReferenceExcceptions will haunt us throughout our solution. My solution for this problem is simple: we can use paged array(array of arrays) instead of simple, one dimensional array.
LargeList implementation
Read more: Codeproject