Hello
I am reading up a bit on how memmory is used in the .NET Framework and have a few question
about the stack-based approach
* I understand that the stack is used to provide a layer of abstractio
between the CLR and the underlaying memory hardware (porting to anothe
architecture should not change the program, i.e you dont work with register
directly)
* I understand that the stack help create variable scope, since it only exist a
long as the defining object (method etc) lives in the stack - once poped the variabl
goes out of scope
* What about the following cod
int a = 1
// ten other calls which is added to the stack, leaving a as the 11t
// stack element
int b = a
Does the stack have to be poped all the way down to the position wher
a is stored, and then push back the stack contents again? I dont see this a
a probable solution which makes me think the stack might support "non traditional
access? Can the CLR read from any stack position (Peek(int frame)) or what
* The same goes for the memory management - the GC looks for active reference
from to the objects on the stack. Does the application roots hold "duplicate information
on references - That is once a reference type is pushed to the stack, it is also assigned t
an application root. And likewize - when a reference type pops of the stack, does th
associated application root get cleared (if so there are there any reference counting bein
done in the root to know that ALL refrences to an objekt on the heap isn't on the stack an
more, so it is not cleared prematurly)
I've read that the stack-based look up should be (slightly) faster then the heap lookups
which means there should be an alterate way of reading the stack (not yourself but fo
the CLR / GC). Of course the stack is local to a thread and the heap is not, so I guess som
kind of locking is needed to ensure the contents of the heap is threadsafe
All and any feedback on this will be a big help
Cheers..
