• FeepingCreature (23/23) Jul 23 2021 Since the GC can sometimes cause delays that can make problems
• Joakim =?UTF-8?B?QnLDpG5uc3Ryw7Zt?= (2/6) Jul 23 2021 Ohh nice. That will be useful! Thank you for the post :)

FeepingCreature <feepingcreature gmail.com> writes:

Since the GC can sometimes cause delays that can make problems 
for latency-sensitive programs, it may be useful to notice when 
it has run.

To that end, I've adapted Brendan Gregg's killsnoop ( 
https://github.com/brendangregg/perf-tools/blob/master/killsnoop 
) to `gcsnoop`, a tool to supervise `tgkill` syscalls (used by 
the GC for `SIGUSR1`/`SIGUSR2`) and log time, PID and GC delay.

https://gist.github.com/FeepingCreature/a2efe19f15eb582af274b23002c25706

Since it uses the kernel event tracing API, it needs to run as 
root.

Time is seconds since boot.

Sample output:

```
$ sudo ./gcsnoop  -t
Tracing GC runs. Ctrl-C to end.
TIMEs            COMM             PID        TGID       LENGTH
355487.807757    gctest-360995    360996     360995     1.364406
355489.930831    gctest-360995    360996     360995     1.291132
355492.119666    gctest-360995    360996     360995     1.403598
355494.446310    gctest-360995    360996     360995     1.543637
^C
Ending tracing...
```

Joakim =?UTF-8?B?QnLDpG5uc3Ryw7Zt?= <notfornow dev.null.com> writes:

On Friday, 23 July 2021 at 08:16:03 UTC, FeepingCreature wrote:
 Since the GC can sometimes cause delays that can make problems 
 for latency-sensitive programs, it may be useful to notice when 
 it has run.

 [...]

Ohh nice. That will be useful! Thank you for the post :)