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.
-
Show this thread
-
Replying to @pcwalton
That would be nice, though one hurdle is statically knowing the cost of allocation. When we get something on the stack today we know statically that allocation basically is too cheap to meter. Worst case on the heap is serious CPU. Good research problem.
1 reply 0 retweets 4 likes -
Replying to @davidcrawshaw @pcwalton
Worst case on the stack is blowing it. I don't think stack allocation provides any way to avoid the hard problems here.
1 reply 0 retweets 0 likes -
Replying to @andygocke @pcwalton
There's lots of code I can statically verify has a maximum allocation size and that is safe to put on the stack. Especially as on some 64-bit OSs you can allocate stacks enormous address space to the stack and demand page it in. (And there are languages with growing stacks!)
1 reply 0 retweets 0 likes -
Replying to @davidcrawshaw @pcwalton
I see this as basically isomorphic to a nursery, except that IME generational tends to handle growing beyond the nursery better than bouncing between stack growths
1 reply 0 retweets 2 likes -
Replying to @andygocke @davidcrawshaw
Yes, this is a very important point. People don’t realize how similar a nursery is to stack allocation.
1 reply 0 retweets 5 likes -
Rsp += size Vs copying gc is quite a difference! Stack is far cheaper
2 replies 0 retweets 1 like -
Isn't nursery allocation also just bumping a pointer by size and comparing with arena max? That's how I've made a simple implementation before.
2 replies 0 retweets 0 likes -
Replying to @jashmatthews @pcwalton and
That's the allocation part (rsp -= Size). I was talking about the *release*. With stacks, release is also just bumping a pointer, and done as soon as possible, keeping everything compact. With nurseries, you have to copy out the still-live objects, with pointer chasing.
2 replies 0 retweets 0 likes -
Replying to @EyalL @jashmatthews and
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.
2 replies 0 retweets 0 likes
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 reply 0 retweets 1 like -
Replying to @andygocke @pcwalton and
Also, whether or not the object requires reference identity
0 replies 0 retweets 0 likes
End of conversation
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.