Garbage profiler

[vilterp]

Ever seen a @time printout like this:

5091.986425 seconds (5.59 G allocations: 324.011 GiB, 57.83% gc time, 5.70% compilation time)

…and wondered what the types are of all those objects which are being allocated and collected? This PR is for you…

It generates a report of how many objects of each type are being freed during each garbage collection.

Usage

file = open("gc-profile.csv", "w")
GC.start_garbage_profile(file)

# ... the code you want to profile ...

GC.stop_garbage_profile()
flush(file) # TODO: figure out how to do this from C...

Output

A CSV file with these columns:

• gc_epoch: an integer that starts at 0 and increases each time the garbage collector runs
• type: type of julia object being freed
• num_freed number of that type freed during that GC epoch

e.g.:

gc_epoch,type,num_freed
1,Foo,5
1,Bar,6
2,Foo,3
2,Bar,2

Output is streamed to this file as the program runs.

To aggregate this over all GC epochs, I've been using csvsql to run do a group by:

$ csvsql --query 'select type, sum(num_freed) from "gc-profile" group by type order by sum(num_freed) desc' gc-profile.csv > gc-profile-agg.csv

Notes

• mimics the callback approach of Heap snapshot #42286

issues / improvements

• is this threadsafe? i.e. can the allocator be called into from multiple threads, which might lead to mutating the hash map concurrently?
• put a timestamp on each log line
• put GC type (full vs. incremental) on each log line
• enable logging & profiling with one function call? can be defined in Julia

Future work

• get stack traces of allocations (especially useful to attribute generic types like Array{UInt8, 1})
• maybe output as PProf memory profile format, like in this article (scroll down to see graphviz output): https://www.freecodecamp.org/news/how-i-investigated-memory-leaks-in-go-using-pprof-on-a-large-codebase-4bec4325e192/

[DilumAluthge]

You have trailing whitespace on the following lines:

src/gc-garbage-profiler.cpp:90:}    
src/gc-garbage-profiler.cpp:146:    

[timholy]

Some kind of memory profiling would be awesome. I assume you've seen this alternative, but if not: #33467. If we had that, would you still want this?

[NHDaly]

(I think this is still in Draft, so i've removed me and Jameson as reviewers. Let me know when you're ready for review Pete, and i'll add us back)

[DilumAluthge]

FYI, you will need to fix the analyzegc failures.

[vilterp]

@timholy good question. This seemed like the fastest way to get a basic handle on our garbage problem, but it does immediately beg the question of where the allocations come from. So, I would still love to get a memory profiler with stacks!

[vilterp]

Folded into #42768