|Lot of text there with no context.
trønderen wrote:There is no real reason why stack frames are allocated edge to edge!
In C/C++ there were library calls that allowed one to chop the stack off. To reset it to a specific point. I never used it, so I don't know why it existed. Might have been performance or error handling. That call would have certainly been easier (and faster) if frames were next to each other.
However I also believe that is not the case for Java. I believe I looked at the source code for that at one point and it was just allocating on the heap.
trønderen wrote:Stack relative addressing never goes outside the current frame
In C and C++ one can overwrite the frame. I have in fact done so in the past.
Since both Java and C# support native code overwriting the frame is also possible there.
trønderen wrote:Stack frames could be allocated from the heap, with space is occupied only as long as a function call is active
That is somewhat simplistic. Allocations of any sort still require a mechanism to deallocate it.
So for example a standard in C/C++ (at least when I looked at source code) was that local variable were allocated. Might have even been in the stack frame. Then the deallocate was when the frame was freed on exit.
That is why they were (or are) on the stack frame. Because the deallocation is already there.
Heap deallocation on the other hand is a different mechanism.
trønderen wrote:Then, a given amount of RAM would be capable of handling a much larger number of threads.
As stated that is wrong. Memory is not the only limitation for the number of threads. Not to mention that no developer should ever consider the idea that an unlimited or large number of threads is a 'good' idea.
trønderen wrote:Even though you with desktop PCs can just plug in another 64 GiB of RAM to satisfy stack needs
Just noting that I have never seen a computer that actually allows for the full addressable range of 64 bits. Certainly no desktop PC does that. So one cannot just keep plugging it in.
And cloud servers are always limited also. Sometimes to very surprising low limits.
trønderen wrote:(such as embedded), this is not always possible. Yet, lots of programmers recoil in horror
Because all resources, not just memory, is scarce. If you add complication to the processing model then it will require more resources. There is no way around that.
trønderen wrote:If the allocation cost worries you, lots of optimizations are possible,
The discussion however is not about me (and the general audience) but rather you.
If you want to fix it then do so.
I have in the past replaced the entire heap in C compiler eco system.
Certainly you could also do the same for the Stack Frame allocation. So do it. I suspect you will find that the deallocation part is going be complicated but doable.
trønderen wrote:I never heard of any software (compiler, run time system) allocating stack frames on the heap
As I suggested when I looked I found Java (JVM source code) to do that.
Following has a response that suggests the same thing.