Description
openedon Jan 6, 2022
The allocation profiler in #42768 doesn't provide Types for all allocations. There are two types of codepaths which allocations go through:
- generated code calling
jl_gc_alloc_(jl_ptls_t ptls, size_t sz, void *ty)
orjl_gc_alloc_string
injulia_internal.h
: these functions know the type of the object being allocated.- which then (sometimes) calls
jl_gc_pool_alloc
/jl_gc_big_alloc
- which then (sometimes) calls
- generated code calling
jl_gc_pool_alloc
orjl_gc_big_alloc
ingc.c
directly: these functions do not know the type of the object being allocated.
The latter paths make it difficult to record the type of the allocation, since the type is not passed in — code is generated which calls it with just the size, and then sets the type later.
Another previous profiler PR, #33467, refactored the second codepath to take the type, and modifies the codegen to call the modified codepath, but hasn't been finished. For now, julia's Profile.Allocs functionality (introduced in #42768, #43868, #44043) doesn't do this.
Instead, for those types, we emit the type as Profile.Allocs.UnknownType
in the allocations profile.
Experiments on a large codebase seem to show around ~40% of allocations have UnknownType, so the tool was still mostly useful. Still, getting the rest would be great!
Fixing this would require either passing the type of the allocation through to those functions by changing the codegen, or removing the instrumentation from those functions and instead emitting the instrumentation directly in the codegen.