-2

As far as I know the concepts of stack and heap when applied to memory refer to data structures used to manage memory.

If these are abstract terms that are not enforced by the language (ie. C#) and there are devices and systems that don't implement memory virtualization using such concepts; then why are these two terms used on basically every book or reference text to explain automatic and dynamic data allocation? Shouldn't these texts explain data allocation using more abstract concepts?

trincot
  • 317,000
  • 35
  • 244
  • 286
underthevoid
  • 513
  • 1
  • 6
  • 17
  • Have you read, for example, [this question on the stack/heap](https://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap?rq=1)? – Putnam Jul 05 '20 at 03:12
  • @Putnam Yes I have. Why? – underthevoid Jul 05 '20 at 03:14
  • If you read the other thread, what exact part don't you understand? – CodingYoshi Jul 05 '20 at 03:38
  • 2
    "*If these are abstract terms that are not enforced by the language*" That's the wrong presumption in this case. The C# [standard](https://standards.iso.org/ittf/PubliclyAvailableStandards/c075178_ISO_IEC_23270_2018.zip) explicitly refers to "*heap*" and "*stack*". There is in fact a `stackalloc` keyword. – dxiv Jul 05 '20 at 03:39
  • @dxiv what about systems and devices that don't implement stack and heap? C# only supports systems that implements a stack and a heap? – underthevoid Jul 05 '20 at 03:41
  • 1
    @underthevoid Would you have an example of such that runs C#? Hypothetically, a system like that would need to emulate the expected heap and stack behaviors in order to comply with the standard. – dxiv Jul 05 '20 at 03:43
  • @dxiv Hmm that makes sense. I think my confusion was on the fact that stack and heap are created and managed by the CPU and the OS and I know that not all systems implements these concepts. That was a hypothetical question indeed, I didn't have a specific system in mind, I just assumed there should have one. Ok then, thank you sir. – underthevoid Jul 05 '20 at 03:48
  • The .NET managed memory heap has slmost nothing to do with the machine architecture and pretty much nothing to do with the OS. It's implemented by the core of the run-time. Most machine architectures understand stacks, even those that rely on registers for return addresses and call parameters. The OSes on those architecture take advantage of that. If a machine/OS combination was completely stack-averse, implementing a stack is very easy to do – Flydog57 Jul 05 '20 at 04:16
  • Does this answer your question? [Memory allocation: Stack vs Heap?](https://stackoverflow.com/questions/4487289/memory-allocation-stack-vs-heap) –  Jul 05 '20 at 09:50
  • 1
    CPU stack and heap are not abstract things, but physical things. Unless we talk about a stack as a data structure and there is no heap there, and this is not the same thing, only the concept of stack is shared. Otherwise, as every thing, stack and heap are abstract concepts... that the human mind created and made real by producing CPUs and programming languages. –  Jul 05 '20 at 11:04
  • .NET (and C#) does not "implement" physical stack and heap: any generated IL code is like any assambly language, but in OO, and is transformed to the target platform to use the CPU binary language and its registers architecture. All CPUs have stack and heap management in the hardware itself. –  Jul 05 '20 at 11:12

1 Answers1

2

I've never read the C# spec, but I've been using the language since well before it was released in 2002.

The stack and heap may be abstract, but the .NET implementations of C# include

  • The managed memory heap. Allocations (using new) of reference types result in memory being allocated from this heap (conceptually there is a single heap, the normal implementation uses more than one). This heap is managed by the Garbage Collector - references into this heap are tracked, and when an object allocated on this heap no longer has any references, it becomes eligible for collection. How this all works is an implementation detail, but the concept is required.

  • Function calls require a place to store the return address and the call parameters. Not all machine architecture store these in a stack (though I think every architecture I've seen includes a stack into which excess call parameters (more than can be passed in registers) will spill over into).

  • Local variables (value type variables and references to instances of reference types) need a place to be stored. Their scope is bound to the lifetime of the function call. They tend to be stored in a stack as well.

It's worth noting that not all local value type variables are now stack-resident. With the advent of variables captured in a closure and of async functions, the compiler can do magic tricks; storing seemingly local value type variables in instances of hidden classes.

Flydog57
  • 6,851
  • 2
  • 17
  • 18
  • So the heap cited in the standards always refer to a fully managed heap created and maintained by the CLR? What about the citations about a hypothetical stack? Does the standard imply that there have to be a OS-level stack? The generated CIL have instructions that modifies a stack - does that CIL rely on the CLR to know what to do at runtime? Thanks in advance for your answer! – underthevoid Jul 05 '20 at 04:28