Why a large piece of the facility and why do we care?

Question

I read about heaps of Generations and Large object. But I still don't understand what is the point (or benefit) of having a large heap of objects?

What could have gone wrong (in terms of performance or memory) if the CLR simply relied on Generation 2 (given that the threshold for Gen0 and Gen1 is small for processing large objects) to store large objects?

Answer 1

Garbage collection not only eliminates objects that are not tied to it, it also compacts the heap. This is a very important optimization. This not only improves memory efficiency (without unused holes), but also makes the processor cache more efficient. The cache is very interesting for modern processors, they are an order of magnitude faster than the memory bus.

Compacting is done simply by copying bytes. It takes time. The larger the object, the greater the likelihood that the cost of copying it outweighs the possible improvements in the use of the CPU cache.

Thus, they conducted a bunch of tests to determine the breakeven point. And reached 85,000 bytes as a cutoff point, where copying no longer improves performance. With a special exception for double arrays, they are considered "large" when the array has more than 1000 elements. This is another optimization for 32-bit code, a large object heap allocator has a special property that allocates memory at addresses that are aligned at 8, as opposed to a regular generation generator that allocates only alignment at 4. This alignment is a big deal for double, reading or writing an incorrectly aligned double is very expensive. Oddly enough, rare information Microsoft never mentions arrays for a long time, not sure about that.

Fwiw, there are many programmers who are longing for a large heap of an object that does not compact. This inevitably starts when they write programs that consume more than half of all available address space. Then you should use a tool like a memory profiler to find out why the program is bombed, despite the fact that there is still a lot of unused virtual memory. Such a tool shows holes in the LOH, unused pieces of memory, where a large object used to live, but garbage was collected. This is the inevitable price of LOH; a hole can be reused by distributing for an object that is equal to or smaller in size. The real problem is that the program needs to be allowed to consume all of the virtual memory at any time.

A problem that otherwise completely disappears by simply running the code on a 64-bit operating system. A 64-bit process has 8 terabytes of available virtual memory address space, 3 orders of magnitude larger than a 32-bit process. You just can't run dry.

In short, LOH makes code more efficient. By using the available address space of virtual memory is less efficient.

---

UPDATE, .NET 4.5.1 now supports compaction of the LOH property, GCSettings.LargeObjectHeapCompactionMode . Beware of the consequences.

Answer 2

The significant difference between the heap of small objects (SOH) and the heap of large objects (LOH) is that the memory in SOH is compacted during assembly, while LOH is not compressed, because this article . Worth multi-large large objects. As in the examples in the article, say, it takes 2 cycles to move a byte in memory, then it takes 8 ms to compact an 8 MB object on a computer with a frequency of 2 GHz, which is a big cost. Given large objects (arrays in most cases) are quite common in practice, I believe that the reason Microsoft associates large objects in memory and offers LOH.

BTW, according to this post , LOH usually does not create problems with fragments of memory.

Answer 3

If the size of the object is greater than some fixed value (85,000 bytes in .NET 1), the CLR puts it in a bunch of large objects. This optimizes:

• Placement of objects (small objects do not mix with large objects)
• Garbage collection (LOH collected only on full GC)
• Defragment memory (LOH - never rarely compressed)

Answer 4

The principal thing is that it is unlikely (and quite possibly a bad design) that the process will create many short-lived large objects, so the CLR allocates large objects into a separate heap, on which it runs GC on a different schedule to a regular heap, http: //msdn.microsoft.com/en-us/magazine/cc534993.aspx

Answer 5

I am not an expert in the CLR, but I would suggest that having a dedicated heap for large objects can prevent unnecessary GC miscalculations of existing generations. Highlighting a large object requires a significant amount of continuous free memory. To ensure that out of the scattered "holes" in heaps of generations, you will need frequent compromises (which are only performed with GC loops).