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
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 cp
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
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 qu
On Thu, Aug 18, 2022 at 5:11 PM Jan Mercl <0xj...@gmail.com> wrote:
> On Thu, Aug 18, 2022 at 10:34 AM T L wrote:
>
> > When I investigate something, I ask questions in communities firstly, to
> save time.
>
> To save your time at the expense of more time wasted by others. Such
> an approach is r
On Thu, Aug 18, 2022 at 10:34 AM T L wrote:
> When I investigate something, I ask questions in communities firstly, to save
> time.
To save your time at the expense of more time wasted by others. Such
an approach is rightfully frowned upon.
Doing your own research first, asking about things wh
On Thu, Aug 18, 2022 at 11:30 AM Kurtis Rader wrote:
> On Wed, Aug 17, 2022 at 8:18 PM 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 pro
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 all
For me the adaptive stack size does not work as expected.
[mateusz@arch avg]$ go version
go version devel go1.20-c8000a18d6 Mon Aug 15 17:07:57 2022 + linux/amd6
https://go.dev/play/p/B4qeIbnv2ci
I've set the stackDebug in runtine to 1.
stackdebug runtime output: https://pastebin.com/sLLfw62
The initial allocation size is exported, you can use the runtime/metrics
package to look at it. Something like this:
package main
import (
"fmt"
"runtime/metrics"
)
func main() {
s := []metrics.Sample{{Name: "/gc/stack/starting-size:bytes"}}
metrics.Read(s)
fmt.Printf("%d\n"
10 matches
Mail list logo
