Skip to content

Commit

Permalink
runtime: delete a very stale comment
Browse files Browse the repository at this point in the history
This comment claims mark termination re-scans stacks and uses the
write barrier to determine how much of the stack needs to be
rescanned. This hasn't been true since we introduced the hybrid write
barrier and deleted stack rescanning with CL 31766 in Go 1.8.

Updates #17503 I suppose.

Change-Id: I5e90f25020c9fa6f146ec6ed0642ba2b4884c2a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/498435
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
  • Loading branch information
aclements authored and gopherbot committed May 26, 2023
1 parent 4c1d8bf commit 76bb0ca
Showing 1 changed file with 0 additions and 6 deletions.
6 changes: 0 additions & 6 deletions src/runtime/mbarrier.go
Original file line number Diff line number Diff line change
Expand Up @@ -112,12 +112,6 @@ import (
// compiler will generate a write barrier for writes through that
// pointer (because it doesn't know it's not a heap pointer).
//
// One might be tempted to ignore the write barrier if slot points
// into to the stack. Don't do it! Mark termination only re-scans
// frames that have potentially been active since the concurrent scan,
// so it depends on write barriers to track changes to pointers in
// stack frames that have not been active.
//
//
// Global writes:
//
Expand Down

0 comments on commit 76bb0ca

Please sign in to comment.