code review 132480043: runtime: increase nosplit area to 192

runtime: increase nosplit area to 192

In CL 131450043, which raised it to 160,
I'd raise it to 192 if necessary.
Apparently it is necessary on windows/amd64.

One note for those concerned about the growth:
in the old segmented stack world, we wasted this much
space at the bottom of every stack segment.
In the new contiguous stack world, each goroutine has
only one stack segment, so we only waste this much space
once per goroutine. So even raising the limit further might
still be a net savings.

Fixes windows/amd64 build.

[rsc, 2014-08-30 04:56:46]

Hello r (cc: golang-codereviews@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go/

[rsc, 2014-08-30 04:56:52]

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

runtime: increase nosplit area to 192

In CL 131450043, which raised it to 160,
I'd raise it to 192 if necessary.
Apparently it is necessary on windows/amd64.

One note for those concerned about the growth:
in the old segmented stack world, we wasted this much
space at the bottom of every stack segment.
In the new contiguous stack world, each goroutine has
only one stack segment, so we only waste this much space
once per goroutine. So even raising the limit further might
still be a net savings.

Fixes windows/amd64 build.

TBR=r
CC=golang-codereviews
https://codereview.appspot.com/132480043

[dvyukov, 2014-08-30 05:08:59]

>One note for those concerned about the growth:

Does it actually increase wastage? It seems that it leaves total guard area size
the same, but increases nosplit area at the cost of making small stack
optimization less efficient. Why is StackSmall size not important?

[gobot, 2014-08-30 06:29:49]

This CL appears to have broken the windows-386 builder.
See http://build.golang.org/log/996c46b322fd5014fa6ebb77d6432c71b74bd4e1

[aram2, 2014-08-30 09:30:02]

Thanks. Now I will be able to remove a whole bunch of ugly hacks from
the Solaris runtime.

-- 
Aram Hăvărneanu

[rsc, 2014-08-30 17:29:21]

On Sat, Aug 30, 2014 at 1:08 AM, <dvyukov@google.com> wrote:

> One note for those concerned about the growth:
>>
>
> Does it actually increase wastage? It seems that it leaves total guard
> area size the same, but increases nosplit area at the cost of making
> small stack optimization less efficient. Why is StackSmall size not
> important?
>

It does increase wastage. An ordinary splitting function must always make
sure there are StackLimit bytes below it, in case it calls a nosplit
function chain. So moving the number I am moving affects the instruction
selection optimization but also how much space is actually available.