Click here to Skip to main content
15,902,114 members
Home / Discussions / Design and Architecture
   

Design and Architecture

 
AnswerRe: Multiple classes calling another same classs Pin
jschell29-Jan-23 11:05
jschell29-Jan-23 11:05 
QuestionDebate reactive programming with me! Pin
Mike Nakis18-Jan-23 3:08
Mike Nakis18-Jan-23 3:08 
AnswerRe: Debate reactive programming with me! Pin
Mircea Neacsu18-Jan-23 3:58
Mircea Neacsu18-Jan-23 3:58 
AnswerRe: Debate reactive programming with me! Pin
Richard MacCutchan18-Jan-23 4:41
mveRichard MacCutchan18-Jan-23 4:41 
AnswerRe: Debate reactive programming with me! Pin
Gerry Schmitz18-Jan-23 5:16
mveGerry Schmitz18-Jan-23 5:16 
AnswerRe: Debate reactive programming with me! Pin
jschell22-Jan-23 8:50
jschell22-Jan-23 8:50 
AnswerRe: Debate reactive programming with me! Pin
jochance7-Mar-23 9:38
jochance7-Mar-23 9:38 
QuestionHeap stack allocation Pin
trønderen15-Jan-23 13:10
trønderen15-Jan-23 13:10 
(I brought this up as a sidetrack in a Lounge thread. Even though I ask out of curiosity only, not any 'need' or immediate problem, the question is on the technical side, so I move it over hereSmile | :)

There is no real reason why stack frames are allocated edge to edge! The stack frame head 'previous frame' pointer could go anywhere. Stack relative addressing never goes outside the current frame. Traditionally, with a million objects, each running its own thread, each of them has allotted a stack for its maximum call depth. This can bind up quite a few megabytes that are hardly if ever used, most certainly not all at the same time. Never ever are every single thread preempted at its very deepest nesting of calls at exactly the same time. In a non-preemptive, co-routine based system, they won't all yield (or whatever it is called in your favorite co-routine package) at the maximum stack depth, all at the same time.

Stack frames could be allocated from the heap, with space is occupied only as long as a function call is active. Then, a given amount of RAM would be capable of handling a much larger number of threads. Especially in event driven architectures, a large fraction of threads idle at a low stack level. They receive an event and go into a nest of calls for handling it, and then return to the low stack level waiting for the next event. The thread might do some sort of yield halfway, but the great majority of threads would be back to 'ground base', or at a moderate call nesting level, most of the time.

The argument against heap allocation is of course the processing cost. There are (/were) machines offering micro coded entry point instructions doing stack allocation from a buddy heap, essentially unlinking the top element from the free list for the appropriate frame size. Function return links the frame back to the top of the list. This requires a couple of memory cycles for each operation. What is that on the total instruction budget for a modern style method call?

Even though you with desktop PCs can just plug in another 64 GiB of RAM to satisfy stack needs, in other systems (such as embedded), this is not always possible. Yet, lots of programmers recoil in horror over buddy allocation: It causes lots internal fragmentation! 25% with binary buddies! Well, but how much can you save in stack requirements? Besides, lots of architectures demand word, doubleword or paragraph stack alignment anyway - that leads to internal fragmentation/waste as well!

If the allocation cost worries you, lots of optimizations are possible, in particular if frame allocation is the responsibility of the caller. E.g. if a function's stack frame has a lot of unused (internal fragmentation) space calls a function asking for a small frame, it could fit in that internal fragmentation space, not requiring another heap allocation. There are dozens of such optimization.

I never heard of any software (compiler, run time system) allocating stack frames on the heap. I never heard of anyone using the micro coded buddy stack frame allocation on the one architecture I know of providing it. Is that because I am ignorant? Smile | Smile | :) Is heap stack allocation 'commonplace' anywhere? Or has it been considered and rejected? If that is the case, what were the arguments for rejecting it?
AnswerRe: Heap stack allocation Pin
jschell22-Jan-23 9:08
jschell22-Jan-23 9:08 
GeneralRe: Heap stack allocation Pin
trønderen23-Jan-23 4:26
trønderen23-Jan-23 4:26 
GeneralRe: Heap stack allocation Pin
jschell24-Jan-23 10:09
jschell24-Jan-23 10:09 
GeneralRe: Heap stack allocation Pin
jsc4225-Jan-23 1:15
professionaljsc4225-Jan-23 1:15 
GeneralRe: Heap stack allocation Pin
harold aptroot23-Jan-23 1:03
harold aptroot23-Jan-23 1:03 
GeneralRe: Heap stack allocation Pin
trønderen23-Jan-23 4:46
trønderen23-Jan-23 4:46 
GeneralRe: Heap stack allocation Pin
jschell24-Jan-23 10:12
jschell24-Jan-23 10:12 
QuestionSetting Up Client Test Environments Pin
Kevin Marois28-Dec-22 9:48
professionalKevin Marois28-Dec-22 9:48 
AnswerRe: Setting Up Client Test Environments Pin
jschell17-Jan-23 4:34
jschell17-Jan-23 4:34 
AnswerRe: Setting Up Client Test Environments Pin
jochance7-Mar-23 19:23
jochance7-Mar-23 19:23 
QuestionHas x:bind in WinUI 3 effectively killed commanding and converters? Pin
greatoceansoftware23-Dec-22 5:53
greatoceansoftware23-Dec-22 5:53 
AnswerRe: Has x:bind in WinUI 3 effectively killed commanding and converters? Pin
Gerry Schmitz28-Dec-22 16:24
mveGerry Schmitz28-Dec-22 16:24 
GeneralRe: Has x:bind in WinUI 3 effectively killed commanding and converters? Pin
greatoceansoftware29-Dec-22 14:56
greatoceansoftware29-Dec-22 14:56 
QuestionImplementing Google Contacts in WPF App Pin
Kevin Marois13-Dec-22 6:31
professionalKevin Marois13-Dec-22 6:31 
AnswerRe: Implementing Google Contacts in WPF App Pin
Gerry Schmitz14-Dec-22 9:08
mveGerry Schmitz14-Dec-22 9:08 
GeneralRe: Implementing Google Contacts in WPF App Pin
Kevin Marois14-Dec-22 10:22
professionalKevin Marois14-Dec-22 10:22 
GeneralRe: Implementing Google Contacts in WPF App Pin
Gerry Schmitz15-Dec-22 8:07
mveGerry Schmitz15-Dec-22 8:07 

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.