I hope someday we can stop thinking of "stack" and "heap" as the two fundamentally different modes of memory allocation and instead reframe memory allocation as a continuum of strategies, from bump allocation to segregated fit to best fit to compacting, etc.
Not a fair comparison IMO, because the stack frame *can’t* have any live objects when you release. You don’t have to copy out of the nursery either if all the objects are dead. The real cost is the cost of scanning the objects in the nursery. That is a cost, but not that high.
-
-
The real reason to promote heap objects to the stack in an optimally implemented GC’d language is to enable SROA-like optimizations. That generally has a higher benefit than avoiding the cost of marking the nursery.
-
Correct, but this gets into the benefit of knowing lifetime, which is helpful for every memory management system
- 1 more reply
New conversation -
-
-
But it is a fair comparison, because the LIFO restriction is what you pay for stack allocation, and you gain this benefit in return. Better compactness, no copying needed, no scanning and no pointer chasing
-
I think you can get the same benefits with heap allocation. IIUC Erlang processes just drop their private heap on finishing. No scanning, no pointer chasing, no copying. Go was exploring the something similar with the ROC but without language restrictions.
- 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.