mirror
/
go
mirror of https://github.com/golang/go.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

runtime: delete a very stale comment 

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>
This commit is contained in:
Austin Clements 2023-05-25 21:43:33 -04:00 committed by Gopher Robot
parent 4c1d8bf54b
commit 76bb0caa5c
1 changed files with 0 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
src/runtime/mbarrier.go
View File

@ -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:
//