-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
runtime: allow no-escape slices of unknown capacity to be allocated to the stack more aggressively #58215
Comments
See also a related proposal regarding maps: #58214 |
Currently all of our stack frames are fixed size, so allocating anything of dynamic size on the stack is a big project. You can simulate what you want like this:
That will stack-allocate if n <= 64 and heap allocate otherwise. I guess we could do that transformation automatically, but we'd need to know the right number for |
Taking out of the proposal process, as this is just an optimization. There's no new API. |
To add on to what @randall77 said, we briefly considered some kind of off-stack-but-bound-to-stack-frames allocator for dynamically-sized things (and other things that escape for some of the more "trivial" reasons), but the total win is unclear when there are workarounds that applications are using (like what @randall77 pointed out). |
Thank you @randall77 for the above hint . Will try it out. This is indeed a bit of a hack... |
Context
Whenever a slice is allocated with a variable capacity (e.g. make([]int, 0, n)), the compiler concludes it escapes to the heap,
even though the slice does not actually escape.
Examples:
Notice that this contrasts with escaping conclusions about similar constructs with maps:
Proposal
I propose to adopt a more aggressive strategy to allocate slices on the stack whenever possible,
whether the capacity is known at build time or not.
Snippet (ii) should be detected as no escape (I believe it is at some point, and we revert to escaping because of the
variable capacity). This would make the escape analysis consistent with maps.
The decision to allocate non-escaping slices to the stack or to the heap should be deferred to runtime,
favoring stack whenever the capacity fits and resorting to heap only for the larger slices.
At the very least, this should favor well-abiding functions that provide a predictable capacity in the call to make (such as snippet (ii)). Growing dynamically the slice is probably a case we could still leave to the heap.
The text was updated successfully, but these errors were encountered: