On Saturday, August 20, 2022 at 10:58:10 PM UTC+8 tapi...@gmail.com wrote:
> On Friday, August 19, 2022 at 12:14:55 AM UTC+8 k...@google.com wrote: > >> On Wednesday, August 17, 2022 at 8:18:35 PM UTC-7 tapi...@gmail.com >> wrote: >> >>> I'm a bit wondering about how the following case will be affected by the >>> change: >>> 1. Initially, there is one goroutine, which stack size is large at the >>> time of a GC process. >>> 2. After the GC process, a large quantity of goroutines start. They all >>> need small stacks. >>> But now the runtime will allocate a very large stack for each of them. >>> >>> Then is much memory wasted? >>> >> >> Kind of. Your description is correct, the runtime will allocate larger >> stacks for each of the new goroutines. But it doesn't really waste memory, >> it just causes the program to reach the next GC earlier. At that GC, stacks >> will shrink, as will the start size for subsequent goroutines. So it won't >> really waste memory, but waste some CPU for a possibly extra GC. >> It isn't perfect; for instance we only shrink stacks 2x at each GC, so if >> the starting size is way too large it might take a couple GCs to shrink >> sufficiently. >> > > I wrote a program to make some tests: https://go.dev/play/p/oDYrAsZz_3i > > It looks the new GC pacer doesn't count new stack memory as new allocated > heap memory. > So large new stacks will not make the program to reach the next GC earlier. > > Since Go 1.18, the stack sizes (the real sizes, not the 2^n sizes) and > global pointers contribute in calculating target heap memory: > https://go.dev/doc/gc-guide#GOGC, so that large stack sizes will cause > large GC intervals. > More precisely, Go 1.18 uses the 2^n stack sizes, whereas Go 1.19 uses the real stack sizes, > > It seems that the outputs indicate there are some hidden goroutines which > cause the calculated average stack sizes > much smaller than expected. > > BTW, in the runtime docs, https://pkg.go.dev/runtime, "# MB stacks" and "# > MB globals" are listed but not shown in the format line. > > > > >> >> >>> Will the stacks of the new goroutines shrink at the next GC process? >>> >> >> Yes. The larger stack sizes are only on goroutine start. The runtime >> doesn't forbid shrinking below the start size. >> >> >>> >>> On Saturday, August 13, 2022 at 10:00:58 PM UTC+8 lia...@garena.com >>> wrote: >>> >>>> Hi masters, >>>> >>>> As far as I know, go 1.19 supports self-adaptive stack size when >>>> spawning a goroutine, which intends to decrease the calling times of >>>> morestack that aims to claim more frames from heap. >>>> >>>> After each GC happens, Go runtime will calculate the average stack >>>> usage and the next time, goroutine would created with such a stack size. >>>> >>>> My question is, how do we validate the whole process or check it if >>>> works well or not. >>>> Is there any metric or stack size checking function, or should I use >>>> pprof to peek the alloc part ? >>>> >>>> Kindly thanks for all >>>> >>>> ``` >>>> func main() { >>>> go func() { >>>> // spawn a goroutine started from a fixed stack size >>>> }() >>>> >>>> runtime.GC() >>>> >>>> go func() { >>>> // spawn a goroutine started from an avg stack size. >>>> }() >>>> } >>>> ``` >>>> >>>> >>>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/65d0d331-1851-4198-abb5-3fc8be0a69b2n%40googlegroups.com.
