go/src/runtime/stack.go, branch json-isValidNumber

runtime,cmd/link: increase stack guard space when building with -race

2022-11-18T16:26:25Z

More stuff to do = more stack needed. Bump up the guard space when building with the race detector. Fixes #54291 Change-Id: I701bc8800507921bed568047d35b8f49c26e7df7 Reviewed-on: https://go-review.googlesource.com/c/go/+/451217 Run-TryBot: Keith Randall Reviewed-by: Keith Randall TryBot-Result: Gopher Robot Reviewed-by: Michael Knyszek

runtime: fix a few function names on comments

2022-11-07T19:48:30Z

Change-Id: I9ef4898d68dfd06618c0bd8e23f81a1d2c77a836 Signed-off-by: cui fliter Reviewed-on: https://go-review.googlesource.com/c/go/+/447460 Auto-Submit: Michael Pratt TryBot-Result: Gopher Robot Reviewed-by: Matthew Dempsky Reviewed-by: Michael Pratt Run-TryBot: Michael Pratt

runtime: replace all uses of CtzXX with TrailingZerosXX

2022-10-18T18:06:27Z

Replace all uses of Ctz64/32/8 with TrailingZeros64/32/8, because they are the same and maybe duplicated. Also renamed CtzXX functions in 386 assembly code. Change-Id: I19290204858083750f4be589bb0923393950ae6d Reviewed-on: https://go-review.googlesource.com/c/go/+/438935 Reviewed-by: Keith Randall Reviewed-by: Bryan Mills Auto-Submit: Keith Randall TryBot-Result: Gopher Robot Reviewed-by: Keith Randall Run-TryBot: Keith Randall

runtime: consolidate stkframe and its methods into stkframe.go

2022-09-02T19:08:58Z

The stkframe struct and its methods are strewn across different source files. Since they actually have a pretty coherent theme at this point, migrate it all into a new file, stkframe.go. There are no code changes in this CL. For #54466, albeit rather indirectly. Change-Id: Ibe53fc4b1106d131005e1c9d491be838a8f14211 Reviewed-on: https://go-review.googlesource.com/c/go/+/424516 Reviewed-by: Michael Pratt Reviewed-by: Cherry Mui TryBot-Result: Gopher Robot Run-TryBot: Austin Clements Auto-Submit: Austin Clements

runtime: make getStackMap a method of stkframe

2022-09-02T19:08:56Z

This places getStackMap alongside argBytes and argMapInternal as another method of stkframe. For #54466, albeit rather indirectly. Change-Id: I411dda3605dd7f996983706afcbefddf29a68a85 Reviewed-on: https://go-review.googlesource.com/c/go/+/424515 Reviewed-by: Michael Pratt Reviewed-by: Cherry Mui Run-TryBot: Austin Clements Auto-Submit: Austin Clements TryBot-Result: Gopher Robot

runtime: replace stkframe.arglen/argmap with methods

2022-09-02T19:08:53Z

Currently, stkframe.arglen and stkframe.argmap are populated by gentraceback under a particular set of circumstances. But because they can be constructed from other fields in stkframe, they don't need to be computed eagerly at all. They're also rather misleading, as they're only part of computing the actual argument map and most callers should be using getStackMap, which does the rest of the work. This CL drops these fields from stkframe. It shifts the functions that used to compute them, getArgInfoFast and getArgInfo, into corresponding methods stkframe.argBytes and stkframe.argMapInternal. argBytes is expected to be used by callers that need to know only the argument frame size, while argMapInternal is used only by argBytes and getStackMap. We also move some of the logic from getStackMap into argMapInternal because the previous split of responsibilities didn't make much sense. This lets us return just a bitvector from argMapInternal, rather than both a bitvector, which carries a size, and an "actually use this size". The getArgInfoFast function was inlined before (and inl_test checked this). We drop that requirement from stkframe.argBytes because the uses of this have shifted and now it's only called from heap dumping (which never happens) and conservative stack frame scanning (which very, very rarely happens). There will be a few follow-up clean-up CLs. For #54466. This is a nice clean-up on its own, but it also serves to remove pointers from the traceback state that would eventually become troublesome write barriers once we stack-rip gentraceback. Change-Id: I107f98ed8e7b00185c081de425bbf24af02a4163 Reviewed-on: https://go-review.googlesource.com/c/go/+/424514 Run-TryBot: Austin Clements Auto-Submit: Austin Clements Reviewed-by: Michael Pratt Reviewed-by: Cherry Mui TryBot-Result: Gopher Robot

runtime: fix formula for computing number of padding bytes

2022-08-19T16:04:12Z

In order to prevent false sharing of cache lines, structs are padded with some number of bytes. These bytes are unused, serving only to make the size of the struct a multiple of the size of the cache line. The current calculation of how much to pad is an overestimation, when the struct size is already a multiple of the cache line size without padding. For these cases, no padding is necessary, and the size of the inner pad field should be 0. The bug is that the pad field is sized to a whole 'nother cache line, wasting space. Here is the current formula that can never return 0: cpu.CacheLinePadSize - unsafe.Sizeof(myStruct{})%cpu.CacheLinePadSize This change simply mods that calculation by cpu.CacheLinePadSize, so that 0 will be returned instead of cpu.CacheLinePadSize. Change-Id: I26a2b287171bf47a3b9121873b2722f728381b5e Reviewed-on: https://go-review.googlesource.com/c/go/+/414214 Reviewed-by: Keith Randall Run-TryBot: Michael Pratt Auto-Submit: Michael Pratt Reviewed-by: Keith Randall Reviewed-by: Joedian Reid TryBot-Result: Gopher Robot

runtime: add and use runtime/internal/sys.NotInHeap

2022-08-19T00:29:18Z

Updates #46731 Change-Id: Ic2208c8bb639aa1e390be0d62e2bd799ecf20654 Reviewed-on: https://go-review.googlesource.com/c/go/+/421878 Reviewed-by: Keith Randall Reviewed-by: Keith Randall Reviewed-by: Matthew Dempsky TryBot-Result: Gopher Robot Run-TryBot: Cuong Manh Le

runtime: convert g.parkingOnChan to atomic type

2022-08-17T16:26:22Z

Updates #53821 Change-Id: I54de39b984984fb3c160aba5afacb90131fd47c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/424394 TryBot-Result: Gopher Robot Reviewed-by: Keith Randall Run-TryBot: Cuong Manh Le Reviewed-by: Michael Pratt Auto-Submit: Cuong Manh Le

runtime: measure stack usage; start stacks larger if needed

2022-05-12T22:32:42Z

Measure the average stack size used by goroutines at every GC. When starting a new goroutine, allocate an initial goroutine stack of that average size. Intuition is that we'll waste at most 2x in stack space because only half the goroutines can be below average. In turn, we avoid some of the early stack growth / copying needed in the average case. More details in the design doc at: https://docs.google.com/document/d/1YDlGIdVTPnmUiTAavlZxBI1d9pwGQgZT7IKFKlIXohQ/edit?usp=sharing name old time/op new time/op delta Issue18138 95.3µs ± 0% 67.3µs ±13% -29.35% (p=0.000 n=9+10) Fixes #18138 Change-Id: Iba34d22ed04279da7e718bbd569bbf2734922eaa Reviewed-on: https://go-review.googlesource.com/c/go/+/345889 Run-TryBot: Keith Randall Reviewed-by: Michael Knyszek TryBot-Result: Gopher Robot Reviewed-by: Keith Randall