views:

296

answers:

2

Possible Duplicate:
Why are structs stored on the stack while classes get stored on the heap(.NET)?

Can anyone tell me that how the allocation of memory is done that which object is to be stored in stack and which to be in heap portion of the memory?

+9  A: 

In the Microsoft implementation of the C# compiler and CLR, value types are stored on the stack when the value is a temporary value, local variable or formal parameter, that is neither a closed-over outer variable of an anonymous method nor in an iterator block.

Of course, why store stuff on the stack if you don't need to? Some local variables of value type never get on the stack at all; they stay in registers for their entire lifetimes.

Other values of value types are stored on the heap - boxed value types, value-typed fields on a reference type, and so on.

Value types can of course be stored on neither the stack, nor registers, nor the managed heap; they could be stored in unmanaged memory using some completely other memory manager not under control of the CLR.

(And of course note that using "the" in "the stack" is subtly misleading; there can be many stacks in a process. There need not be just one.)

All this is an implementation detail and subject to change without notice.

Also, obviously stuff allocated with the stack alloc declaration is allocated on the stack.

For more information on this topic see my articles on it:

http://blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-stack-is-an-implementation-detail.aspx

http://blogs.msdn.com/b/ericlippert/archive/2009/05/04/the-stack-is-an-implementation-detail-part-two.aspx

Why do you care? The runtime manages all these details for you so that you don't have to worry about it. Are you just curious, or is this leading to some larger question?

Eric Lippert
"Why do you care?": I can't say for the question asker, but for me, I searched for this information (and also about stack size) some time ago as I was afraid I'll get a stack overflow exception if I had too many structs on the stack.
blizpasta
+4  A: 

3 rules of thumb:

  1. Objects are stored on the heap. These include instances of reference-types and boxed value-types.
  2. Local variables and parameters are stored on the stack. For local value-types, this means that the value itself is stored on the stack. For local reference-types, only the reference will be on the stack (Edit: Exceptions noted by Eric Lippert - value-type locals closed over outer variables, iterator-block value-types).
  3. Fields are stored where the containing instance is located. For example, a value-type field of a class will be stored on the heap. The reference-part of a reference-type field of a struct declared as a local stored on the stack will also be on the stack.
Ani
Rule 2 is wrong. Local variables and parameters are not always stored on the stack. Local variables of value type which are closed-over outer variables are stored on the heap. All locals of value type are stored on the heap if the block is an iterator block. And of course you omit the fact that *even locals "on the stack" might not be on the stack*. They might be enregistered.
Eric Lippert
@Eric Lippert: You're right of course; which is why I hastened to add that these are *rules of thumb*.
Ani
@Eric Lippert: Also, wouldn't you say, given what the C# compiler does to iterator blocks, that it is slightly inaccurate to think of variables declared in those methods as *locals* in the first place?
Ani
How are they not locals? They are variables declared inside a method body; by definition that's a local variable. Do you have some other definition of "local variable" that differs from the definition given in the specification?
Eric Lippert
@Eric Lippert: In terms of the language, yes. But wouldn't locals end up being translated to fields in the private state-machine class that the compiler generates? Isn't this 'implementation detail' crucial to understanding why they end up on the heap?
Ani
Yes, locals are turned into fields. They don't have to be. Iterators could be implemented as fibers, for example, in which case the locals would be on the stack of the fiber. Fibers are too expensive to use for iterators in Windows so we don't use them. But that's an implementation decision made for performance reasons.
Eric Lippert