BTW, the outputs of the test program: $ GODEBUG=gctrace=1 ./main gc 1 @0.006s 4%: 0.035+1.5+0.006 ms clock, 0.14+0/1.5/2.0+0.024 ms cpu, 0->0->0 MB, 8 MB goal, 0 MB stacks, 8 MB globals, 4 P (forced) 2022/08/20 22:46:47 2048 1 gc 2 @2.123s 0%: 0.034+2.6+0.008 ms clock, 0.13+0/2.5/7.1+0.035 ms cpu, 0->0->0 MB, 8 MB goal, 64 MB stacks, 8 MB globals, 4 P (forced) 2022/08/20 22:46:49 8388608 2 GC forced gc 3 @124.390s 0%: 0.045+5.1+0.010 ms clock, 0.18+0/5.1/0+0.041 ms cpu, 0->0->0 MB, 63 MB goal, 128 MB stacks, 8 MB globals, 4 P GC forced gc 4 @244.411s 0%: 0.072+5.0+0.009 ms clock, 0.28+0/5.0/0+0.038 ms cpu, 0->0->0 MB, 118 MB goal, 128 MB stacks, 8 MB globals, 4 P gc 5 @307.129s 0%: 0.076+2.7+0.013 ms clock, 0.30+0/2.7/7.9+0.052 ms cpu, 0->0->0 MB, 118 MB goal, 128 MB stacks, 8 MB globals, 4 P (forced) 2022/08/20 22:51:56 16777216 3 gc 6 @313.134s 0%: 0.098+2.6+0.011 ms clock, 0.39+0/2.5/7.5+0.044 ms cpu, 0->0->0 MB, 118 MB goal, 128 MB stacks, 8 MB globals, 4 P (forced) 2022/08/20 22:52:02 16777216 3
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. > > 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/d185b4fe-2de6-4ef9-94c8-bfd9f14fe1c3n%40googlegroups.com.
