From: Alexey Borzenkov <snaury@gmail.com>
Date: Sun, 27 Mar 2011 21:15:48 +0000 (-0400)
Subject: runtime: fix darwin/amd64 thread VM footprint
X-Git-Tag: weekly.2011-03-28~13
X-Git-Url: http://www.git.cypherpunks.su/?a=commitdiff_plain;h=59a892682908789fe74124f7b97ab11c9c8d2b92;p=gostls13.git

runtime: fix darwin/amd64 thread VM footprint

On darwin amd64 it was impossible to create more that ~132 threads. While
investigating I noticed that go consumes almost 1TB of virtual memory per
OS thread and the reason for such a small limit of OS thread was because
process was running out of virtual memory. While looking at bsdthread_create
I noticed that on amd64 it wasn't using PTHREAD_START_CUSTOM.
If you look at http://fxr.watson.org/fxr/source/bsd/kern/pthread_synch.c?v=xnu-1228
you will see that in that case darwin will use stack pointer as stack size,
allocating huge amounts of memory for stack. This change fixes the issue
and allows for creation of up to 2560 OS threads (which appears to be some
Mac OS X limit) with relatively small virtual memory consumption.

R=rsc
CC=golang-dev
https://golang.org/cl/4289075
---

diff --git a/src/pkg/runtime/darwin/amd64/sys.s b/src/pkg/runtime/darwin/amd64/sys.s
index 10d8f96df5..39398e065d 100644
--- a/src/pkg/runtime/darwin/amd64/sys.s
+++ b/src/pkg/runtime/darwin/amd64/sys.s
@@ -146,8 +146,7 @@ TEXT runtime·bsdthread_create(SB),7,$0
 	MOVQ	mm+16(SP), SI	// "arg"
 	MOVQ	stk+8(SP), DX	// stack
 	MOVQ	gg+24(SP), R10	// "pthread"
-// TODO(rsc): why do we get away with 0 flags here but not on 386?
-	MOVQ	$0, R8	// flags
+	MOVQ	$0x01000000, R8	// flags = PTHREAD_START_CUSTOM
 	MOVQ	$0, R9	// paranoia
 	MOVQ	$(0x2000000+360), AX	// bsdthread_create
 	SYSCALL