12

In the file runtime/proc.go of the Go source code, there are many comments referring to safe point functions, which appear to be related to points in time where it is safe to garbage collect. However, I could not find any definitions of these functions.

What are safe point functions, what are they used for, and what are some examples of such functions?

Mohsin Aljiwala
  • 2,457
  • 2
  • 23
  • 30
merlin2011
  • 71,677
  • 44
  • 195
  • 329
  • 5
    These are implementation details of the GC and runtime, which aren't accessible in the language itself. If you're asking our of curiosity about how this specific version of the runtime works, that's one thing, but it's of no consequence to any user written code. – JimB Sep 28 '15 at 21:07
  • @JimB, I am trying to understand the threading library implementation in Go (that is, the details of how goroutines are implemented and scheduled), and this appears to be at least tangentially related to the GC behavior and safe points. You are correct, this has nothing to do with usage of the language. – merlin2011 Sep 28 '15 at 21:09
  • 2
    I'm not up to date on the current runtime, but this being closely tied to the GC, [this talk](http://talks.golang.org/2015/go-gc.pdf) may be of interest to you, with [video](https://www.youtube.com/watch?v=aiv1JOfMjm0). – JimB Sep 28 '15 at 21:22
  • @JimB, Thanks! Will take a look. – merlin2011 Sep 28 '15 at 21:27
  • 1
    If you [search for runSafePointFn](https://github.com/golang/go/search?utf8=%E2%9C%93&q=runSafePointFn&type=Code), you'll find this key comment: "Any P entering _Pidle or _Psyscall from now on will observe p.runSafePointFn == 1 and will call runSafePointFn when changing its status to _Pidle/_Psyscall.". You'll see that `reentersyscall`, called by `entersyscall`, sets the P's status to `_Psyscall` after checking `runSafePointFn`. – twotwotwo Sep 28 '15 at 22:58
  • 3
    So, following the breadcrumbs, system calls and other things that leave goroutines idle (sync/channel operations) can lead to a GC safepoint. Also heard the function prelude responsible for growing the stack as needed (`morestack`) can sometimes lead to switching goroutines in recent versions of Go; I don't know, but maybe that can lead to a safepoint as well. – twotwotwo Sep 28 '15 at 23:03

1 Answers1

4

Here is everything I could dig up on this topic.

I found some discussion about Go's GC safepoints here.

It looks like safe points (as used in the Go implementation) are effectively the same as the traditional definition of a safe point:

key points where the GC can track what all variables and registers hold

Another user on the same thread mentions that the GC

folds the preemption points into the stack checks during function prologs

and that the source for this claim is the following: https://github.com/golang/go/issues/10958

According to this post on the golang-dev mailing list, safepoints are also called "call sites".

To gain some insight into the nature of Go's safepoints, I think it's important to look at the evolution of its GC. This post mentions the following:

Prior to Go 1.5, Go has used a parallel stop-the-world (STW) collector.

Go 1.5 introduces a concurrent collector.

Another answer to that question mentions:

As of Go 1.7, the one remaining source of unbounded and potentially non-trivial stop-the-world (STW) time is stack re-scanning.

As of 1.8, it looks like worst-case stop-the-world times have been improved.

Also, here is the current implementation of Go's garbage collector. If you read through the comments, you'll see that it is a non-generational mark-sweep collector. You can read more about this here: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.udz1kjk3b

Finally, here is an old post by Gil Tene on the golang-dev mailing list which motivates the use of a moving garbage collector. He claimed (at the time in 2012) that Go was using a "conservative, non-relocating collector" and he discussed the characteristics of safepoints which would permit a long-running garbage collector.

While Go's garbage collector has been moving away from long pauses and is now a "concurrent, tri-color, mark-sweep collector", it's still a non-generational GC. It also looks like Go's GC is building on GC ideas from the 70s rather than modern, enterprise approaches.

It looks like Go's notion of a safepoint is more in line with the traditional notion of a safepoint rather than a safepoint with modern qualities which permit generational garbage collection.

Community
  • 1
  • 1
rudolph1024
  • 962
  • 1
  • 12
  • 32