Working principles about stack, heap, garbage collector, val

/*

Author: Jiangong SUN

*/

I 've been long time confused about the reference type, value type, stack, heap and gabarge collector. How do they work? Today I try to clarify all these concepts by defining them, and listing their differences.

 

Reference type:

Answer:

String
All arrays, even if their elements are value types
Class types, such as Form
Delegates

 

 

Value type:

Answer:

Value type consist of 2 main categories: struct and enum
Struct include: numeric types (integral type, floating-point types, decimal), bool, user defined structs.

Integral type include: sbyte, byte, char, short, ushort, int, uint, long, ulong

Floating-point types include: float and double.

Enumerations, since their underlying type is always SByte, Short, Integer, Long, Byte, UShort, UInteger, or ULong

Float: precision: 7 digits
Double: precision: 15-16 digits
Decimal: precision: 28-29 significant digits

 

 

Reference type vs. Value type:

Answer:

When value-type instance is created, a single space in memory is allocated to store the value.
When reference-type instance is created, only the reference to the object is created.

 

 

Elements not belong to types:
Namespaces
Modules
Events
Properties and procedures
Variables, constants, and fields

 

 

Reference vs. Pointer:

Answer:

A pointer in C language is like reference in CSharp, but pointer is more powerful than reference. For example, you can perform arithmetic on pointer.

All you can do in reference, you can do it with pointer. But not vice versa.

C # references cocould be implemented by opaque handles that are meaningful only to the garbage collector.

Reference:

 

Value types store on Stack?

Answer:

Value types sometimes store on Stack. But value types doesn' t always store on Stack.

Here are the cases when value types don't store on 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

 

Why Value types stores on stack but reference types do not?

Answer:

The short answer is "because they can". And since the stack is cheap, we do put them on the stack when possible.

 

 

Stack:

Answer:

Stack is that the memory on the bottom of the stack always lives longer than the memory on the top of the stack; the stack is strictly ordered.

The objects that are going to die first are on the top, the objects that are going to die last are on the bottom. and with that guarantee, we know that the stack will never have holes, and therefore will not need compacting. we know that the stack memory will always be "freed" from the top, and therefore do not need a free list. we know that anything low-down on the stack is guaranteed alive, and so we do not need to mark or sweep.

The stack is the memory set aside as scratch space for a thread of execution. when a function is called, a block is reserved on the top of the stack for local variables and some bookkeeping data. when that function returns, the block becomes unused and can be used the next time a function is called. the stack is always reserved in a LIFO order; the most recently reserved block is always the next block to be freed. this makes it really simple to keep track of the stack; freeing a block from the stack is nothing more than adjusting one pointer.

 

 

Heap:

Answer:

The heap is memory set aside for dynamic allocation. unlike the stack, there's no enforced pattern to the allocation and deallocation of blocks from the heap; you can allocate a block at any time and free it at any time. this makes it much more complex to keep track of which parts of the heap are allocated or free at any given time; there are using custom heap allocators available to tune heap performance for different usage patterns.

Reference:

 

 

 

Stack vs Heap:

Answer:

The choice of allocation mechanic has to do only with the known required lifetime of the storage.

There are not just only stack and heap in memory, Registers are neither on the stack or the heap, and it is perfectly legal for a value type to go in a register if there is one of the right size.

A lot of people seem to think that heap allocation is expensive and stack allocation is cheap. they are actually about the same, typically. it's the deallocation costs-the marking and sweeping and compacting and moving memory from generation to generation-that are massive for heap memory compared to stack memory.

 

Better to use Stack or Heap?

Answer:

It is better to use a stack than a GC heap if you can.

 

 

Storage locations in Memory:

There are three kinds of storage locations: stack locations, heap locations, and registers.
Long-lived storage locations are always heap locations.
Short-lived storage locations are always stack locations or registers.
There are some situations in which it is difficult for the compiler or runtime to determine whether a particle storage location is short-lived or long-lived. in those cases, the prudent demo-is to treat them as long-lived. in particle, the storage locations of instances of reference types are always treated as though they are long-lived, even if they are provably short-lived. therefore they always go on the heap.

 

 

Garbage Collector:

When a garbage collection is saved Med there are three phases: mark, sweep and compact.

In the "mark" phase, we assume that everything in the heap is "dead ". the CLR knows what objects were "guaranteed alive" when the collection started, so those guys are marked as alive. everything they refer to is marked as alive, and so on, until the transitive closure of live objects are all marked.

In the "sweep" phase, all the dead objects are turned into holes.

In the "compact" phase, the block is reorganized so that it is one contiguous block of live memory, free of holes.

 

 

Garbage collecton generations:

Answer:

Version 1: in detail

The CLR collector is generational.

Objects start off in the "short lived" heap. if they has ve they eventually move to the "medium lived" heap, and if they has ve there long enough, they move to the "long lived" heap. the GC runs very often on the short lived heap and very seldom on the long lived heap; the idea is that we do not want to have the expense of constantly re-checking a long-lived object to see if it is still alive. but we also want short-lived objects to be reclaimed swiftly.

Version 2: working principle

When an object is first created, it is put into generation 0. when the generation 0 is filled up, the garbage collector is invoked. the objects that keep ve the garbage collection in the first generation are promoted onto the next higher generation, generation 1. the objects that keep ve garbage collection in generation 1 are promoted onto the next and the highest generation, generation 2. this algorithm works efficiently for garbage collection of objects, as it is fast. note that generation 2 is the highest generation that is supported by the garbage collector.

Extremely large objects are stored in a special heap that has different compaction policy.

Reference:

 

 

I hope this post can do help in your work! Enjoy coding!