3 ms·

Isn't that stack/heap distinction between managed and native code just a technicality? I mean, for native code, your stack is also just allocated space in memor

Isn't that stack/heap distinction between managed and native code just a technicality? I mean, for native code, your stack is also just allocated space in memory, right? Similarly, your stack in a managed language is allocated on the heap of the runtime itself, sure. But in the end, once the managed code starts running, for the code itself it's a stack. Or am I mistaken and there is some special handling of stack memory vs heap memory? As far as I understand, the stack is just a big preallocated block of memory that we start filling up. I agree that the rest of the article is pretty thin, though. It goes into managed code mentioning a tracing GC and reference counting, but doesn't even really explain what it is and doesn't explain memory management at all. I would've expected different allocation strategies like arenas, but this is disappointing

weinzierl 2y ago
"I mean, for native code, your stack is also just allocated space in memory, right?" Yes. At least on Linux the thread stacks and the memory on the heap are usually allocated with the same syscall (mmap) even. So, the difference is not a question of provenance but how the memory is managed. The native stack is the one the (hardware register) stack pointer points to and there can only be one per thread. Since this stack's management is hardware supported it can be very fast and efficient. Of course, nothing prevents you from having as many stacks on the heap as you like and manage them yourself. From all I know this is not what managed languages do, but I think they still rely on the amenities of the hardware supported stack.
deleted 2y ago
[deleted]
bregma 2y ago
Yes, memory is memory in the same sense that exponentiation is just repeated addition of 1 to number. The article isn't really talking about memory so much as discussing storage, which is often colloquially called 'memory' by people who do not deal with it directly. What the article is trying to do is to distinguish between scoped storage and non-scoped storage. Those are two of the 4 types of storage used in a modern programming language abstract machine. All of the 4 types of storage have backing memory allocated in different ways and at different times an initialized through different sequences, but also on modern processors are usually processed in registers, which are synchronized to their backing store through various levels of cache in different ways as well. The article is a very simplistic introduction to basic abstract storage concepts targeted at a complete beginner. I would have expected an article about memory management to discuss the different types of memory, or maybe cacheing, or about how memory allocation and garbage collection works. But it's fine as a very high-level introduction to how storage works in a typical programming language abstract machine.
gpderetta 2y ago
The difference is in the name. Stack allocation is strictly FIFO [1], so it can be implemented very efficiently with just incrementing and decrementing a stack pointer, even on architectures that don't directly have an hardware stack. In principle that stack for local variables doesn't even need to be the same stack as the callstack. It is also strictly thread local. On the other hand an heap (which has nothing to do with the heap data structure) is much more complex. [1] At least across activation frames, of course a compiler can statically generate code that reuses frame slots in a non-FIFO way.

weinzierl 2y ago

"I mean, for native code, your stack is also just allocated space in memory, right?" Yes. At least on Linux the thread stacks and the memory on the heap are usually allocated with the same syscall (mmap) even. So, the difference is not a question of provenance but how the memory is managed. The native stack is the one the (hardware register) stack pointer points to and there can only be one per thread. Since this stack's management is hardware supported it can be very fast and efficient. Of course, nothing prevents you from having as many stacks on the heap as you like and manage them yourself. From all I know this is not what managed languages do, but I think they still rely on the amenities of the hardware supported stack.

deleted 2y ago

[deleted]

bregma 2y ago

Yes, memory is memory in the same sense that exponentiation is just repeated addition of 1 to number. The article isn't really talking about memory so much as discussing storage, which is often colloquially called 'memory' by people who do not deal with it directly. What the article is trying to do is to distinguish between scoped storage and non-scoped storage. Those are two of the 4 types of storage used in a modern programming language abstract machine. All of the 4 types of storage have backing memory allocated in different ways and at different times an initialized through different sequences, but also on modern processors are usually processed in registers, which are synchronized to their backing store through various levels of cache in different ways as well. The article is a very simplistic introduction to basic abstract storage concepts targeted at a complete beginner. I would have expected an article about memory management to discuss the different types of memory, or maybe cacheing, or about how memory allocation and garbage collection works. But it's fine as a very high-level introduction to how storage works in a typical programming language abstract machine.

gpderetta 2y ago

The difference is in the name. Stack allocation is strictly FIFO [1], so it can be implemented very efficiently with just incrementing and decrementing a stack pointer, even on architectures that don't directly have an hardware stack. In principle that stack for local variables doesn't even need to be the same stack as the callstack. It is also strictly thread local. On the other hand an heap (which has nothing to do with the heap data structure) is much more complex. [1] At least across activation frames, of course a compiler can statically generate code that reuses frame slots in a non-FIFO way.