alloc profiler: record pool allocs, even though they'll be missing a type

[vilterp]

merges onto JuliaLang#42768

touches JuliaLang#43688

Description

Some allocations go through the jl_gc_pool_alloc codepath, which doesn't get type. This PR captures the stacktrace and size from that codepath anyway. The real solution involves possibly changing LLVM codegen to generate code which pass in a type to jl_gc_pool_alloc.

The alloc profiler decoder will mark these as having type UnknownType.

Evaluation

Experimentation on https://github.com/vilterp/HeapSnapshotParser.jl/blob/master/test/runtests.jl shows it's only picking up an additional 1% of allocs:

# this PR
julia> res = Profile.Allocs.@profile sample_rate=0.01 HeapSnapshotParser.parse_snapshot("testdata/empty-repl.heapsnapshot")
julia> prof = Profile.Allocs.fetch()
julia> num_allocs = length(prof.allocs)
29605

# base alloc profiler
julia> res = Profile.Allocs.@profile sample_rate=0.01 HeapSnapshotParser.parse_snapshot("testdata/empty-repl.heapsnapshot")
julia> prof = Profile.Allocs.fetch()
julia> num_allocs = length(prof.allocs)
29335

julia> 29335.0 / 29605.0
0.990879918932612

A larger proprietary codebase was showing ~10%.

[vilterp]

@NHDaly don't have to merge this now; just something to have in our back pocket in case it comes up in code review discussion…

[vilterp]

@vchuravy does it seem reasonable that only a small percentage of allocs would go through jl_gc_pool_alloc? What makes the decision of whether it uses that or jl_gc_alloc_? Thanks.

[vilterp]

hold on, this is not right, since jl_gc_alloc calls jl_gc_pool_alloc… 

[vchuravy]

I am surprised that only the minority of allocations are type-less. Effectively all small allocation that happen in compiled code will go directly to jl_gc_pool_alloc instead of jl_gc_alloc

cc: @pchintalapudi

[pchintalapudi]

Julia has quite a few different allocating methods, mixed in at the Julia/LLVM level and at the C level.

So all julia.gc_alloc_obj intrinsics are first lowered to GCAllocBytes intrinsics in late-gc-lowering, and then those calls are inlined in final-gc-lowering to point to either jl_gc_pool_alloc or jl_gc_big_alloc as-if jl_gc_alloc_ had been called, which is why those bare calls appear in the final compiled output.

However, array and string allocations are handled in C, and are therefore not seen or inlined by the optimization passes. My guess is that most of the allocations in whatever benchmark is being used are primarily array or string allocations, and that's why only a small percentage of allocations seem to skip jl_gc_alloc. If one was to create benchmark primarily allocating structs without arrays or strings, I'd guess that'd show 100% of allocations being missed.

[vilterp]

Thanks for the info. I’m pretty sure my benchmark allocated a few thousand structs, but I’m not sure I was counting right. Will take another pass at getting these percentages on different workloads.

[vilterp]

Superseded by #14, which avoids double counting