有关CLR和堆内存的基本问题 [英] Basic question on CLR and heap memory

问题描述

我在.net中阅读有关CLR的信息:
当CLR加载时，堆将在SOH和LOH中进行分区.
1>那时启动应用程序时，CLR根据其大小将堆分配给应用程序.

[所以我的第一个问题是
CLR如何在开始时计算应用程序所需的堆大小?]

2> LOH堆具有Gen0，Gen1和Gen2区域.
3>新创建的对象在Gen0中分配.
4>在垃圾收集时，活动对象从Gen(N)向上移动到Gen(N + 1)区域上一级

我的问题是:
1>单个应用程序是否可以分配堆的整个Gen0区域?
2>每个应用程序堆内存的大小是否有限制?

i read about CLR in .net as:
When CLR loads heap is partitioned in SOH and LOH.
1>when application is started at that time heap is allocated by CLR to application depending on its size.

[So my first question is that
how CLR calculates needed size of heap to application at start?]

2>LOH heap has Gen0,Gen1,and Gen2 regions.
3>Newly created objects are allocated in Gen0.
4>At Garbage collection time live objects are moves one level up from Gen(N) to Gen(N+1) region

My questions are :
1>Is it possible for an single application to allocate whole Gen0 region of heap?
2>Or there is any size restriction on size for each application heap memory?

推荐答案

当然，CLR无法提前知道"应用程序要从堆中请求多少内存.就我所知，堆仅受整个系统中可用的总堆池的限制，而这又取决于应用程序可用的(系统范围内的)总内存.

如果由于某种原因，您需要开发内存预算应用程序，该应用程序预先获取一定数量的堆内存，以确保某些关键内存密集型应用程序的可靠性提高，则可以使用子分配内存技术.这应该给您一个想法.
http://en.wikipedia.org/wiki/Block_suballocation [ http://msdn.microsoft.com/en-us/magazine/cc534993.aspx [ ^ ].

我认为应用程序级别没有任何限制. CLR堆结构由系统上的所有应用程序共享.

这是它的一些基本背景:具有托管内存和托管指针而不是常规"指针的全部目的是使引用对象与物理内存(或者更确切地说是将事件线性，虚拟，分页内存呈现为平面)之间的松散耦合.地址空间(根据Windows操作系统设计以及许多其他现代操作系统).引用机制得以维护，始终保证引用可以访问实际对象，只有当该对象变得不可访问时，才可以对其进行垃圾回收.同时，可以在运行期间移动对象在OS应用程序地址空间中的位置.

此处说明了垃圾收集的机制和可达性的作用:
http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29 [ ^ ].

特别是，这种堆体系结构允许CLR动态优化堆结构，防止过多的碎片等.为此，CLR可以将内存分配从一个进程转移到另一个进程.当某个进程需要更多的LOH内存堆时，CLR会尝试提供它，并在有助于解决给定时间内存分配问题的情况下重新安排堆结构.

—SA

Of course, CLR cannot "know" in advance how much memory an application is going to request from the heap. To best of my knowledge, the heap in only limited by the total heap pool available in the whole system, which is, in turn, depends on total (system-wide) memory available to applications.

If, by some reason, you would need to develop memory-budgeted application which gets some guaranteed amount of heap memory in advance, to ensure increased dependability of some critical memory-heavy application, you could use the suballocation memory techniques. This should give you an idea.
http://en.wikipedia.org/wiki/Block_suballocation[^].

As to .NET, it is not oriented this way, so you would need considerable effort to achieve this in any more or less universal ways. In principle, this is quite possible though.



The detail of Large Object Heap with CLR is covered here:
http://msdn.microsoft.com/en-us/magazine/cc534993.aspx[^].

I don''t thing there are any restrictions on the application level. The CLR heap structure is shared by all of the applications on the system.

Here is some basic background for it: The whole point of having managed memory and managed pointer instead of "regular" pointers is to make a loose coupling between referenced object and physical memory (or rather event linear, virtual, paged memory presented as a flat address space, according to the Windows OS design, as well as many other modern OS). The mechanism of references is maintained the way that a reference is always guarantee to access the real object, which can be garbage-collected only when it becomes unreachable. At the same time, the position of the object in the OS application address space can be moved during run time.

The mechanism of garbage collection and the role of reachability is explained here:
http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29[^].

In particular, such heap architecture allows CLR to optimize the heap structure on the fly, prevent excessive fragmentation, etc. For this purpose, CLR can shift allocation of the memory from one process to another. When some process requires more heap of LOH memory, CLR tries to deliver it, rearranging the heap structure if it helps to resolve the memory allocation problem at a given moment of time.

—SA

就内存而言，对象仅受内存本身大小的限制.
但是，大型对象由于清理相关的碎片成本而成为昂贵的资源.
浏览 http://msdn.microsoft.com/en-us/magazine/cc534993.aspx [< ^ ].
因此，应尽可能少用它们.

In terms of memory, your objects are only restricted by the size of memory itself.
However, large objects are expensive resources due to fragmentation costs associated with their cleanup.
Go through http://msdn.microsoft.com/en-us/magazine/cc534993.aspx[^].
So they should be used as sparingly as possible.

这篇关于有关CLR和堆内存的基本问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！