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: ensuring support of debug.asyncpreemptoff #37575

Open
derekparker opened this issue Feb 28, 2020 · 7 comments
Open

runtime: ensuring support of debug.asyncpreemptoff #37575

derekparker opened this issue Feb 28, 2020 · 7 comments
Milestone

Comments

@derekparker
Copy link
Contributor

@derekparker derekparker commented Feb 28, 2020

This came up during a routinely scheduled meeting between the Delve team and folks from the Go team and it was suggested by @heschik to open an issue about this to ensure it stays on folks minds.

Delve leverages the debug.asyncpreemptoff in order to disable the functionality on Windows [0] (where it won't play well with debuggers) and may use it on other platforms as well to disable the functionality when run under Delve [1] [2].

This issue is mostly to get feedback and assurance that we can rely on this feature for the foreseeable future.

@aarzilli
Copy link
Contributor

@aarzilli aarzilli commented Mar 1, 2020

Crossreferencing #36494

@dmitshur
Copy link
Member

@dmitshur dmitshur commented Mar 2, 2020

@dmitshur dmitshur added this to the Backlog milestone Mar 2, 2020
@dmitshur dmitshur changed the title runtime: Ensuring support of debug.asyncpreemptoff runtime: ensuring support of debug.asyncpreemptoff Mar 2, 2020
@laboger
Copy link
Contributor

@laboger laboger commented Mar 2, 2020

Likewise #37126. This affects gdb also.

@aclements
Copy link
Member

@aclements aclements commented Mar 2, 2020

Thanks for bringing this up. I don't think there's any particular reason why this would go away in the future. There are a lot of benefits to cooperative preemption (mostly it's much cheaper when it works), so that's not going away, and the two systems are relatively orthogonal, so it's quite easy to turn off the async part.

One thing we may have to watch out for is doing optimizations that assume async preemption works. For example, it would be nice to more aggressively eliminate function prologues where we can prove the stack check isn't necessary, but that creates more situations where cooperative preemption isn't sufficient. Maybe we still can't do optimizations like that because of their impact on debuggers.

There's an idea I've been kicking around for a while... What if the runtime provided more of a debugger agent? I think you would still break in to a process using ptrace/whatever, and use DWARF for symbolization of data and source code. But the runtime could provide a debug API to the scheduler in particular, which seems to be where most of the friction is. For example, the debugger would probably still inject INT3s for breakpoints, but may handle them by immediately reflecting them back to the runtime: ask the scheduler to suspend that goroutine (or all user goroutines) and immediately resume the OS process, even though the user is still sitting at a debug prompt.

@aarzilli
Copy link
Contributor

@aarzilli aarzilli commented Mar 2, 2020

For example, the debugger would probably still inject INT3s for breakpoints, but may handle them by immediately reflecting them back to the runtime: ask the scheduler to suspend that goroutine (or all user goroutines) and immediately resume the OS process, even though the user is still sitting at a debug prompt.

I don't think this helps with the current issues we are having. For macOS the problem is that we are receiving signals at all, bouncing everything back to the process wouldn't make this faster it would just make breakpoints twice as slow. For linux we don't have any problems (that we know of) and this would just make breakpoints twice as slow. In theory it could help with the windows problem, however the debugger knows where the breakpoints are, while the runtime doesn't.

@aclements
Copy link
Member

@aclements aclements commented Mar 2, 2020

I'm not sure I understand why this would make breakpoints twice as slow. It seems like the same total work. Admittedly, this is only a rough sketch of an idea; there could well be important details I'm overlooking.

@aarzilli
Copy link
Contributor

@aarzilli aarzilli commented Mar 2, 2020

In terms of context switches between the debugger and the process we are currently doing one when we get the breakpoint signal if we make the process do some of the work it would be two context switches.

On macOS the biggest source of latency is communication between debugserver and delve and we have to do it every time we have to route a signal so that would at minimum make it twice as slow, possibly N time slower (N = number of threads) if the runtime has to send a signal to stop each thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.