4 ms·

The way I understand this, and that I think some other people in this thread misunderstand, is that this is not a change to the Go language in any way. The way

by tinco 9y ago

The way I understand this, and that I think some other people in this thread misunderstand, is that this is not a change to the Go language in any way. The way Go works is that you can spawn green threads, and the Go runtime will magically run them concurrently, in such a way that you do not have to worry about many problems usually associated with concurrent programming. This proposal seeks to modify the way the "magically" part works. Right now, it suggests that what Go does is to 'cooperatively' preempt at function prologues. This change would instead allow the runtime to preempt at a choice of "safe points" the compiler suggests throughout your Go code. Note that this is a little bit in the gray area between cooperative and non-cooperative. It's not like the runtime will just randomly preempt, it still requires cooperation from the code to have these safe points. But maybe I'm misunderstanding the details. Anyway, not much changes for the Go programmer. The Go programmer can expect his code to be a little more predictable, at the cost of having his code be a little less performant, this performance cost I think will not be significant, if not fully compensated by the increased parallelism. All the promises the Go runtime makes towards the programmer will still hold.

zzzcpan 9y ago
The proposal is to turn all go code into safe points.
mseepgood 9y ago
> at the cost of having his code be a little less performant Where did you read this? The proposal states: "This approach will solve the problem of delayed preemption with zero run-time overhead."
- uluyol 9y ago
  Hopefully this can actually decrease overhead. Go's garbage collector has some short STW pauses that require stopping the world. It you have one thread misbehaving by running a tight loop right now, the rest of the threads will sit there spinning until that one thread reaches a preemption point. With explicit preemption, that period would be much shorter.
hinkley 9y ago
This reminds me of the safe point mechanism in IBMs J9 JVM to make GC cheaper by shortening the mark phase.
masklinn 9y ago
> This proposal seeks to modify the way the "magically" part works. Right now, it suggests that what Go does is to 'cooperatively' preempt at function prologues. This change would instead allow the runtime to preempt at a choice of "safe points" the compiler suggests throughout your Go code. That's how it already works, it's just that safepoints only get introduced at function prologues. This is an issue as CPU-heavy functions without any non-inlined function calls mean very few safe points which is problematic for GC and timely scheduling and may even lock up the entire system. Previous attempts were made to add loop preemption but there are issues with that approach. The approach in TFA is to make safe points "opt-out", all Go code would be considered safe by default with some "unsafe" regions being excluded. As the author states, this would make Go preemptive rather than cooperative ("I propose that we implement fully non-cooperative preemption"). > Anyway, not much changes for the Go programmer. The Go programmer can expect his code to be a little more predictable Go programmers can expect their code to be a little less predictable, not more: currently your code is guaranteed to run uninterrupted between two function calls, that will not be the case anymore. In theory it should not make any difference, in practice it will probably uncover concurrency bug you're currently shielded from by the runtime's behaviour (though likely not that many as you can already have multiple routines running in parallel).
- skj 9y ago
  Not just function prologues, but also channel operations. Might sound like a minor nit but it's a pretty important nit.
  - masklinn 9y ago
    Fair enough, though I'd assume that to be considered IO and would very much expect to be a place which always yields.
chimeracoder 9y ago
> Right now, it suggests that what Go does is to 'cooperatively' preempt at function prologues. This change would instead allow the runtime to preempt at a choice of "safe points" the compiler suggests throughout your Go code. This is incorrect. Go has had preemptive scheduling (instead of cooperative) since at least 1.2 (possibly 1.1). The proposal here is to make it preempt at arbitrary points, not just at certain points. The points at which it currently can preempt is far greater than simply function prologues, which is why full preemption has very little impact on the end user (it already appears to preempt at essentially arbitrary points).

by tinco 9y ago

zzzcpan 9y ago

The proposal is to turn all go code into safe points.

mseepgood 9y ago

> at the cost of having his code be a little less performant Where did you read this? The proposal states: "This approach will solve the problem of delayed preemption with zero run-time overhead."

uluyol 9y ago
Hopefully this can actually decrease overhead. Go's garbage collector has some short STW pauses that require stopping the world. It you have one thread misbehaving by running a tight loop right now, the rest of the threads will sit there spinning until that one thread reaches a preemption point. With explicit preemption, that period would be much shorter.

hinkley 9y ago

This reminds me of the safe point mechanism in IBMs J9 JVM to make GC cheaper by shortening the mark phase.

masklinn 9y ago

> This proposal seeks to modify the way the "magically" part works. Right now, it suggests that what Go does is to 'cooperatively' preempt at function prologues. This change would instead allow the runtime to preempt at a choice of "safe points" the compiler suggests throughout your Go code. That's how it already works, it's just that safepoints only get introduced at function prologues. This is an issue as CPU-heavy functions without any non-inlined function calls mean very few safe points which is problematic for GC and timely scheduling and may even lock up the entire system. Previous attempts were made to add loop preemption but there are issues with that approach. The approach in TFA is to make safe points "opt-out", all Go code would be considered safe by default with some "unsafe" regions being excluded. As the author states, this would make Go preemptive rather than cooperative ("I propose that we implement fully non-cooperative preemption"). > Anyway, not much changes for the Go programmer. The Go programmer can expect his code to be a little more predictable Go programmers can expect their code to be a little less predictable, not more: currently your code is guaranteed to run uninterrupted between two function calls, that will not be the case anymore. In theory it should not make any difference, in practice it will probably uncover concurrency bug you're currently shielded from by the runtime's behaviour (though likely not that many as you can already have multiple routines running in parallel).

skj 9y ago
Not just function prologues, but also channel operations. Might sound like a minor nit but it's a pretty important nit.
- masklinn 9y ago
  Fair enough, though I'd assume that to be considered IO and would very much expect to be a place which always yields.

chimeracoder 9y ago

> Right now, it suggests that what Go does is to 'cooperatively' preempt at function prologues. This change would instead allow the runtime to preempt at a choice of "safe points" the compiler suggests throughout your Go code. This is incorrect. Go has had preemptive scheduling (instead of cooperative) since at least 1.2 (possibly 1.1). The proposal here is to make it preempt at arbitrary points, not just at certain points. The points at which it currently can preempt is far greater than simply function prologues, which is why full preemption has very little impact on the end user (it already appears to preempt at essentially arbitrary points).