Why value-types are stored onto Stacks?
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?
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.
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:
- Value types that are fields in a class
- Boxed value types
- Local value types that are outer variables of anonymous methods
- 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.
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.
Your statement isn't totally true. A better version: C# stores local variables on the stack.
And this isn't special or new, (almost) all programming languages use the stack for local variables and method return addresses. There is support for this down to the hardware.
Furthermore, Valuetypes can be local variables or fields inside reference types. So valuetypes are not always stored on the stack. A more helpful statement: referencetypes are never stored on the stack.
So don't focus on the stack too muuch, it's an implementation detail. Learn about value- and reference-types.
Stack operation or Heap operation, they both will be same as you are accessing a memory address which are in two different locations.
Value types are small, int, byte etc, they are small in size and they are referenced very frequently in terms of mathematical computations. Since they are very small in size, 4 to 16 bytes max, (you should not use more then 16 bytes in value type for best performance), alloating such small space on heap and deallocating, garbage collection etc would be very costly.
Every method we enter, on an average we define 10 local value types to use it internally, that will be very costly on heap as reference types.
Stack can grow and shrink easily (not the stack size, but the stack portion used for current Method !!) as the valuetypes are just addressed as offset from stack pointer, and their allocation and deallocation is easy as its simple increment and decrememnt on stackpointer by total size of all valuetypes used.
Where else in reference type, each reference object has its own allocation and sizing, plus CLR has to maintain table of objects which is sort of like index of actual pointers in memory in order to avoid buffer overflows. So one object you use (reference type) actually has two storage, one index entry in CLR's reference table, and actual memory space. Thats why its easy and fast to store value types on stack.