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

dvyukov opened this issue Mar 4, 2015 · 2 comments


None yet
3 participants
Copy link

commented Mar 4, 2015

This is a follow up to change
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.


@dvyukov dvyukov added this to the Go1.5Maybe milestone Mar 4, 2015

@rsc rsc modified the milestones: Unplanned, Go1.5Maybe Jul 21, 2015


This comment has been minimized.

Copy link
Member Author

commented May 24, 2019

This was fixed by f8b2314 right? @aclements


This comment has been minimized.

Copy link

commented May 24, 2019


@aclements aclements closed this May 24, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.