3 ms·
No, outside special code it is impossible to know at compile time how many heap allocation a function will have. The stack has the requirement that its size mu
by afiori 5y ago
No, outside special code it is impossible to know at compile time how many heap allocation a function will have.
The stack has the requirement that its size must be known at compile time for each function. In oversimplified terms its size is going to be the sum of size_of of all the syntactically local variables.
So for example you cannot grow the stack with a long loop, because the same variable is reused over and over in all the iterations.
You can instead grow the heap as much as you want with a simple `while(true){malloc(...)}`.
- morelisp 5y ago> The stack has the requirement that its size must be known at compile time for each function. Not really. You can bump your stack pointer at any time. Even C has alloca and VLAs. In lots of languages it's dangerous and not done because you can stack overflow with horrible results, and some (but not all) performance is lost because you need to offset some loads relative to another variable value, but you can do it. What the stack really has a requirement that any values on it will go full nasal demon after the function returns, so you'd better be absolutely certain the value can't escape - and detecting that is hard.
- chrisseaton 5y ago> No, outside special code it is impossible to know at compile time how many heap allocation a function will have. Huh? def foo: return [new Object, new Object] That'll always bump the TLAB three times. Why not bump it one time for all objects? > The stack has the requirement that its size must be known at compile time for each function. Also huh? For example a local array that has a dynamic size.