My recollection is the stack and heap start at opposite ends of free memory in the Pico C SDK and grow towards each other. I think a read-only stack guard can be enabled that causes a fault if the stack grows too big. Without that guard the stack might overwrite the heap or the other way around. While this could be a security problem, sometimes a stack can jump over the guard.I find these statements to be true but incomplete. Please appeal to safety rather than performance as performance is a function of something else. I believe the heap is just as capable as the stack in most cases.Note for an application-level C program running under Linux you might instead want to allocate as many variables on the stack as possible. In Linux the stack will grow as needed and placing things on the stack will lead to better memory locality and thread safety in a multi-threaded program. On the other hand, stack smashing can be a problem in some security contexts.
You really do highlight the security issues of reentrance.
According to Fido the memory ownership model in Rust is primary designed to track which stack each automatic variable is allocated from in a multi-threaded program. Whether the alternative of a shared heap with global locking is too slow or not depends on the application along with the NUMA characteristics of the hardware.
For example, the Go programming language tends to place automatic variables unexpectedly on the heap when escape analysis fails. This can result in more than 50 percent of execution time spent on heap operations and locking.
Statistics: Posted by ejolson — Sat Oct 05, 2024 12:00 am