Stack and Heap Memory [Answered]
I've been correcting some of my misconception about stack and heap memory allocation. So, this is my final verdict , I just want to make sure that I'm not holding any misconceptions. I had a misconception that all value types are stored on stack and all reference type are stored on heap, which I found out that partially wrong.
So, after some research, this is my final verdict -
"Short lived variables are considered to go on the stack/registers, where long lived variables are considered to go on the heap."
The variable of a reference type just hold the reference (address) of the instance of that reference type, and the instance of a reference type always stored in heap, right? And this variable of reference type can either stay in stack or heap depending on it's lifetime, right?
So, if value type is defined as local variable (including parameter), it will be stored on stack if not captured by closure. If value type is defined as a member of a reference type, then that value type is also going to be stored on the heap? Along with that reference type?
And, whatever variables Closure captures, will always goes to heap, right? As that is considered as long lived.
When we use ref keyword with a value type, it just passes the reference. It doesn't box the value, right?
When we use ref keyword with a value type, it just passes the reference. It doesn't box the value, right?
20 Replies
I think the "short-lived" vs "long-lived" thing isn't relevant, and is confusing you
Variables/fields can be reference or value types. With a value type, the value is stored right there in the variable/field; with a reference type, a block of memory is allocated on the heap, the value is stored in that heap memory, and the variable/field holds a pointer to that memory.
Local variables are stored on the stack, unless they're captured by a closure in which case they might become fields in a compiler-generated class. Fields are stored in whatever memory holds the containing class/struct
"Short lived variables are considered to go on the stack/registers, where long lived variables are considered to go on the heap."no
The variable of a reference type just hold the reference (address) of the instance of that reference type, and the instance of a reference type always stored in heapyes, but no. Today that technically right, but tomorrow the runtime may sometimes allocate it on the stack, because it's cheaper: https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/jit/object-stack-allocation.md
GitHub
runtime/object-stack-allocation.md at main · dotnet/runtime
.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps. - runtime/object-stack-allocation.md at main · dotnet/runtime
Well first, the stack:
You have a function, your functions have variables, the computer need a place to put these.
The easiest way to do it, is the stack, when you run a function, your variables values are put on top of the stack, when exiting the function, all variables declared in this functions are forgotten
whatever variables Closure captures, will always goes to heap, right?closures also may be on the stack, like my previous point, afaik that not the case today, it's the case in java.
And, whatever variables Closure captures, will always goes to heap, right? As that is considered as long lived.I think you are mixing up GC concept of short lived, and long lived the GC only manage heap objects, and there is short, and long lived objects there.
There is also a large object heap, I think
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
✅ This post has been marked as answered!
Hello, thanks for your response and the info about compiler-generated class.
Hello, first of all, thanks for your response. I actually got the idea about long lived and short lived from this article: https://learn.microsoft.com/en-us/archive/blogs/ericlippert/the-truth-about-value-types#:~:text=Code%20in%C2%A0a,required%20by%20M.)
where the author mention about short living and long living concept from activation period of a method. Is it referencing GC concept?
not here
article is 12 year old, today short/long lived objects is more often talked for the objects generation in the GC
The article is very clear to draw a distinction between references and instances of reference types. Your question lost that, I think
Fundamentals of garbage collection
Learn how the garbage collector works and how it can be configured for optimum performance.
I mean, it's true that local variables and parameters tend to be short-lived, and fields tend to be long-lived
in fact, the local variable are destroyed when you exit the function scope
I'd say that's an effect rather than a cause, but it's fine. The article isn't wrong
Seeing the author of the article, i'll question myself before saying article is wrong 
But I think you read it, and its very careful distinction between value types, references, and instances of reference types, and lost the nuance there. If you replace "short-lived" with "local variable" etc, you should find it agrees with what I said above
Yes. So, i guess the choosing of word was wrong for me.
Where a variable (value type or reference) is stored depends on whether it is a local or field. That's cut and dried. The article adds the nuance that most of the time, locals are short-lived and fields are long-lived
Thanks @here
np !