This is undoutably a naive question, but having seen several CLs related to the complication around shrinking a stack via copying, I wonder why the GC does not simply reclaim the extra pages of the stack by marking them free.
I guess this would limit the lower bound a stack could be shrunk to a system package, or whatever is the size above the last shared size class.
There may also be an impact of fragmentation, but in that respect a stack frame is no different from a large string retained on the heap.Is this work necessary for a future moving collector ?
Would it be simpler/safer in 1.6 to shrink stacks via lopping off their tails, rather than copying them?
Thanks for your timeDave--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thanks for your reply Austin. I wasn't really concerned with performance, my question was spurred on by reading Russ' recent CL about teaching the compiler to understand the subtlety of stack allocated arguments passed to long running syscalls.
That's a more realistic scenario than the one I'd come up with. I could see servers with long lived connections or goroutine pools doing this.