Click here to Skip to main content
15,917,618 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
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?
Posted
Updated 29-Oct-12 7:01am
v3

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.

[EDIT]

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
 
Share this answer
 
v2
Comments
Abhinav S 29-Oct-12 13:05pm    
5!
Sergey Alexandrovich Kryukov 29-Oct-12 13:14pm    
Thank you, Abhinav.
--SA
fdiu 29-Oct-12 13:06pm    
please see my updated question.
ok i got answer for my first question

what about remaining two questions,what will be case?
Sergey Alexandrovich Kryukov 29-Oct-12 13:29pm    
I tried to answer in a bit more detail, please see my updated answer, after [EDIT].
--SA
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.
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 29-Oct-12 13:30pm    
I actually already added the same link (a good one, my 5 for your answer) in response to the OP's follow-up questions and tried to answer them, please see.
--SA
Abhinav S 29-Oct-12 13:38pm    
Thank you SA.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900