code review 6938073: cmd/gc: add GOEXPERIMENT=zerostack to clear stack on fu...

cmd/gc: add GOEXPERIMENT=zerostack to clear stack on function entry

This is expensive but it might be useful in cases where
people are suffering from false positives during garbage
collection and are willing to trade the CPU time for getting
rid of the false positives.

On the other hand it only eliminates false positives caused
by other function calls, not false positives caused by dead
temporaries stored in the current function call.

The 5g/6g/8g changes were pulled out of the history, from
the last time we needed to do this (to work around a goto bug).
The code in go.h, lex.c, pgen.c is new but tiny.

[rsc, 2012-12-17 19:32:23]

Hello ken2 (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/

[rsc, 2012-12-17 19:35:07]

*** Submitted as https://code.google.com/p/go/source/detail?r=1542912cf09d ***

cmd/gc: add GOEXPERIMENT=zerostack to clear stack on function entry

This is expensive but it might be useful in cases where
people are suffering from false positives during garbage
collection and are willing to trade the CPU time for getting
rid of the false positives.

On the other hand it only eliminates false positives caused
by other function calls, not false positives caused by dead
temporaries stored in the current function call.

The 5g/6g/8g changes were pulled out of the history, from
the last time we needed to do this (to work around a goto bug).
The code in go.h, lex.c, pgen.c is new but tiny.

R=ken2
CC=golang-dev
https://codereview.appspot.com/6938073

[remyoudompheng, 2012-12-19 21:32:12]

Did you mean on function exit rather than on function entry?
I think I got some occurences of this and it could be interesting to try.

Rémy.

[rsc, 2012-12-20 00:49:58]

On Wed, Dec 19, 2012 at 4:32 PM, Rémy Oudompheng
<remyoudompheng@gmail.com> wrote:
> Did you mean on function exit rather than on function entry?
> I think I got some occurences of this and it could be interesting to try.

I meant entry; I'm pretty sure that's what it does.
We only look for pointers above the stack pointer, so exiting from a function
(moving the stack pointer up) invalidates the frame being exited just fine.
When we call some other function (moving the stack pointer back down)
that's when we need to clear the possible leftovers.

Russ

[bradfitz, 2012-12-20 19:27:22]

FWIW

$ ~/go/misc/benchcmp pre after
benchmark                 old ns/op    new ns/op    delta
BenchmarkBinaryTree17    6609304439   7628303665  +15.42%
BenchmarkFannkuch11      4022145484   4004236646   -0.45%
BenchmarkGobDecode         22689501     28294911  +24.70%
BenchmarkGobEncode         14140080     20895874  +47.78%
BenchmarkGzip             573818598    597825448   +4.18%
BenchmarkGunzip           153709528    182790682  +18.92%
BenchmarkJSONEncode        52379183     84300750  +60.94%
BenchmarkJSONDecode       122344908    203004074  +65.93%
BenchmarkMandelbrot200      4922443      4782015   -2.85%
BenchmarkParse              8182503     10212874  +24.81%
BenchmarkRevcomp         1091600620   1019171563   -6.64%
BenchmarkTemplate         163358779    200874163  +22.97%

benchmark                  old MB/s     new MB/s  speedup
BenchmarkGobDecode            33.83        27.13    0.80x
BenchmarkGobEncode            54.28        36.73    0.68x
BenchmarkGzip                 33.82        32.46    0.96x
BenchmarkGunzip              126.24       106.16    0.84x
BenchmarkJSONEncode           37.05        23.02    0.62x
BenchmarkJSONDecode           15.86         9.56    0.60x
BenchmarkParse                 7.08         5.67    0.80x
BenchmarkRevcomp             232.84       249.39    1.07x
BenchmarkTemplate             11.88         9.66    0.81x


On Mon, Dec 17, 2012 at 11:32 AM, <rsc@golang.org> wrote:

> Reviewers: ken2,
>
> Message:
> Hello ken2 (cc: golang-dev@googlegroups.com),
>
> I'd like you to review this change to
> https://go.googlecode.com/hg/
>
>
> Description:
> cmd/gc: add GOEXPERIMENT=zerostack to clear stack on function entry
>
> This is expensive but it might be useful in cases where
> people are suffering from false positives during garbage
> collection and are willing to trade the CPU time for getting
> rid of the false positives.
>
> On the other hand it only eliminates false positives caused
> by other function calls, not false positives caused by dead
> temporaries stored in the current function call.
>
> The 5g/6g/8g changes were pulled out of the history, from
> the last time we needed to do this (to work around a goto bug).
> The code in go.h, lex.c, pgen.c is new but tiny.
>
> Please review this at
https://codereview.appspot.**com/6938073/<https://codereview.appspot.com/6938...
>
> Affected files:
>   M src/cmd/5g/gsubr.c
>   M src/cmd/6g/gsubr.c
>   M src/cmd/8g/gsubr.c
>   M src/cmd/gc/go.h
>   M src/cmd/gc/lex.c
>   M src/cmd/gc/pgen.c
>
>
>

[rsc, 2012-12-22 15:16:33]

That's about what I expected as far as slowdown. JSON, Gob, and
Template are the highly recursive ones.