Why value-types are stored onto Stacks?

Question

Why does C# (.Net) prefer stack to store value types? What is the primary reason behind this design? Is it because read/write operations to the stack take better advantage of the machine processor?

Also, maybe you can justify why not others?

Answer 1

Eric Lippert discusses this here; firstly, it is incorrect that "value types are stored on the stack". They sometimes are, but not as:

• fields on a class
• captured variables
• variables in an iterator block

When they can be stored on the stack it is a convenient way of modelling their lifetime, but it isn't required to store them on the stack. You could write a compiler+CLI that doesn't have a stack, for example.

Answer 2

C# doesn't store anything on the stack. C# is a programming language. Therefore, a more correct version of your question is why does the Microsoft C# compiler emit CIL instructions to allocate value types on the stack?

Well, first, it only does sometimes. The following do not go on the stack:

1. Value types that are fields in a class
2. Boxed value types
3. Local value types that are outer variables of anonymous methods
4. Local value types that are outer variables of iterator blocks

Second, when it's possible it's done because it's efficient. Basically in the CLR memory model, on the stack deallocation is very cheap relative compared to deallocation on the heap. With locals of value types, you can be sure that no one else except the local will reference the memory so you can get away with using the stack instead of the heap. For details, see Eric Lippert.

Finally, what makes value types special is that they have value-type semantics (copy by value), not that they are sometimes allocated on the stack. There is no requirement in the C# specification that the compiler emit instructions to allocate value types on the stack. What the C# specification does require is that value-types have value-type semantics.

Answer 3

As @Akash indicates, it mostly has to do with memory. During the design of the CLR, it was noted (my guess was from the experience with Java) that representing small, primitive types as objects with handles subjected to the garbage collector caused a lot of tracking overhead. So the designers wanted a "lightweight" object which didn't need to be tracked.

There is no specific requirement in the CLI specification for primitives to be stack allocated; it's an artifact of the implementation on the machine. The essential bit is that the runtime knows where the instances are due to the construction of well-defined patterns of memory (called frames) rather than in the GC's index of allocated objects. On x86 (and similar) machines, this can be done efficiently using the stack.