]> Cypherpunks repositories - gostls13.git/commit
cmd/gc, runtime: enable precisestack by default
authorRuss Cox <rsc@golang.org>
Wed, 19 Feb 2014 22:09:08 +0000 (17:09 -0500)
committerRuss Cox <rsc@golang.org>
Wed, 19 Feb 2014 22:09:08 +0000 (17:09 -0500)
commit53061193f1b35aa6eda405909db41900fdc2c5de
tree885cb24e89927f5ed1000ffecfa4405bc3215b8a
parent1ca1cbea6589802bc0a0fa6b5475de03b913e8f3
cmd/gc, runtime: enable precisestack by default

[Repeat of CL 64100044, after 32-bit fix in CL 66170043.]

Precisestack makes stack collection completely precise,
in the sense that there are no "used and not set" errors
in the collection of stack frames, no times where the collector
reads a pointer from a stack word that has not actually been
initialized with a pointer (possibly a nil pointer) in that function.

The most important part is interfaces: precisestack means
that if reading an interface value, the interface value is guaranteed
to be initialized, meaning that the type word can be relied
upon to be either nil or a valid interface type word describing
the data word.

This requires additional zeroing of certain values on the stack
on entry, which right now costs about 5% overall execution
time in all.bash. That cost will come down before Go 1.3
(issue 7345).

There are at least two known garbage collector bugs right now,
issues 7343 and 7344. The first happens even without precisestack.
The second I have only seen with precisestack, but that does not
mean that precisestack is what causes it. In fact it is very difficult
to explain by what precisestack does directly. Precisestack may
be exacerbating an existing problem. Both of those issues are
marked for Go 1.3 as well.

The reasons for enabling precisestack now are to give it more
time to soak and because the copying stack work depends on it.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/65820044
src/cmd/gc/lex.c
src/pkg/runtime/proc.c