Click here to Skip to main content
15,848,407 members
Home / Discussions / Design and Architecture
   

Design and Architecture

 
QuestionDebate reactive programming with me! Pin
Mike Nakis18-Jan-23 4:08
Mike Nakis18-Jan-23 4:08 
AnswerRe: Debate reactive programming with me! Pin
Mircea Neacsu18-Jan-23 4:58
Mircea Neacsu18-Jan-23 4:58 
AnswerRe: Debate reactive programming with me! Pin
Richard MacCutchan18-Jan-23 5:41
mveRichard MacCutchan18-Jan-23 5:41 
AnswerRe: Debate reactive programming with me! Pin
Gerry Schmitz18-Jan-23 6:16
mveGerry Schmitz18-Jan-23 6:16 
AnswerRe: Debate reactive programming with me! Pin
jschell22-Jan-23 9:50
jschell22-Jan-23 9:50 
AnswerRe: Debate reactive programming with me! Pin
jochance7-Mar-23 10:38
jochance7-Mar-23 10:38 
QuestionHeap stack allocation Pin
trønderen15-Jan-23 14:10
trønderen15-Jan-23 14:10 
AnswerRe: Heap stack allocation Pin
jschell22-Jan-23 10:08
jschell22-Jan-23 10:08 
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


False.

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.

https://stackoverflow.com/questions/26741925/is-frame-in-jvm-heap-allocated-or-stack-allocated[^]
GeneralRe: Heap stack allocation Pin
trønderen23-Jan-23 5:26
trønderen23-Jan-23 5:26 
GeneralRe: Heap stack allocation Pin
jschell24-Jan-23 11:09
jschell24-Jan-23 11:09 
GeneralRe: Heap stack allocation Pin
jsc4225-Jan-23 2:15
professionaljsc4225-Jan-23 2:15 
GeneralRe: Heap stack allocation Pin
harold aptroot23-Jan-23 2:03
harold aptroot23-Jan-23 2:03 
GeneralRe: Heap stack allocation Pin
trønderen23-Jan-23 5:46
trønderen23-Jan-23 5:46 
GeneralRe: Heap stack allocation Pin
jschell24-Jan-23 11:12
jschell24-Jan-23 11:12 
QuestionSetting Up Client Test Environments Pin
Kevin Marois28-Dec-22 10:48
professionalKevin Marois28-Dec-22 10:48 
AnswerRe: Setting Up Client Test Environments Pin
jschell17-Jan-23 5:34
jschell17-Jan-23 5:34 
AnswerRe: Setting Up Client Test Environments Pin
jochance7-Mar-23 20:23
jochance7-Mar-23 20:23 
QuestionHas x:bind in WinUI 3 effectively killed commanding and converters? Pin
greatoceansoftware23-Dec-22 6:53
greatoceansoftware23-Dec-22 6:53 
AnswerRe: Has x:bind in WinUI 3 effectively killed commanding and converters? Pin
Gerry Schmitz28-Dec-22 17:24
mveGerry Schmitz28-Dec-22 17:24 
GeneralRe: Has x:bind in WinUI 3 effectively killed commanding and converters? Pin
greatoceansoftware29-Dec-22 15:56
greatoceansoftware29-Dec-22 15:56 
QuestionImplementing Google Contacts in WPF App Pin
Kevin Marois13-Dec-22 7:31
professionalKevin Marois13-Dec-22 7:31 
AnswerRe: Implementing Google Contacts in WPF App Pin
Gerry Schmitz14-Dec-22 10:08
mveGerry Schmitz14-Dec-22 10:08 
GeneralRe: Implementing Google Contacts in WPF App Pin
Kevin Marois14-Dec-22 11:22
professionalKevin Marois14-Dec-22 11:22 
GeneralRe: Implementing Google Contacts in WPF App Pin
Gerry Schmitz15-Dec-22 9:07
mveGerry Schmitz15-Dec-22 9:07 
GeneralRe: Implementing Google Contacts in WPF App Pin
Kevin Marois15-Dec-22 13:27
professionalKevin Marois15-Dec-22 13:27 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.