Skip to content
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: move fast path of newdefer/freedefer to goroutine stack #10076

Closed
dvyukov opened this issue Mar 4, 2015 · 2 comments
Closed

runtime: move fast path of newdefer/freedefer to goroutine stack #10076

dvyukov opened this issue Mar 4, 2015 · 2 comments

Comments

@dvyukov
Copy link
Member

dvyukov commented Mar 4, 2015

This is a follow up to change https://go-review.googlesource.com/#/c/3967
The change moves freedefer from goroutine stack to system stack, because otherwise nosplit stack overflows with -N as:

runtime.cgocallbackg: nosplit stack overflow
504 assumed on entry to runtime.cgocallbackg
456 after runtime.cgocallbackg uses 48
448 on entry to runtime.cgocallbackg1
512 after runtime.cgocallbackg1 uses -64
504 on entry to runtime.deferreturn
408 after runtime.deferreturn uses 96
400 on entry to runtime.freedefer
64 after runtime.freedefer uses 336
56 on entry to runtime.writebarrierptr
32 after runtime.writebarrierptr uses 24
24 on entry to runtime.writebarrierptr_shadow
-16 after runtime.writebarrierptr_shadow uses 40

newdefer is already on system stack.
For performance reasons we would like to move fast paths of both newdefer and freedefer to goroutine stack.

@randall77

@dvyukov dvyukov added this to the Go1.5Maybe milestone Mar 4, 2015
@rsc rsc modified the milestones: Unplanned, Go1.5Maybe Jul 21, 2015
@dvyukov
Copy link
Member Author

dvyukov commented May 24, 2019

This was fixed by f8b2314 right? @aclements

@aclements
Copy link
Member

Yep

@golang golang locked and limited conversation to collaborators May 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants