alloc profiler: get stacks for pool allocs via wrapper function

[vilterp]

merges into JuliaLang#42768

Add a wrapper around jl_gc_pool_alloc to allow us to instrument it.

managed_malloc taken care of in #20

Before

*: instrumented; red: currently missed

graphviz

digraph G {
  node [shape=box];

  generated_code [label="<generated code>"];

  new_array;
  jl_gc_alloc_string [label="jl_gc_alloc_string *"];
  jl_gc_alloc [label="jl_gc_alloc *"];
  jl_managed_malloc [label="jl_managed_malloc *"]; // https://github.com/vilterp/julia/pull/20
  jl_gc_pool_alloc;
  jl_gc_big_alloc;

  generated_code -> jl_gc_alloc_string;
  generated_code -> new_array;
  generated_code -> jl_gc_alloc;
  generated_code -> jl_gc_big_alloc [color=red];
  generated_code -> jl_gc_pool_alloc [color=red];

  jl_gc_alloc -> jl_gc_pool_alloc;
  jl_gc_alloc -> jl_gc_big_alloc;
  new_array -> jl_gc_alloc;
  new_array -> jl_managed_malloc;
  jl_gc_alloc_string -> jl_gc_pool_alloc;
  jl_gc_alloc_string -> jl_gc_big_alloc;
}

After

*: instrumented; red: currently missed

graphviz

```graphviz digraph G { node [shape=box];

generated_code [label=""];

new_array;
jl_gc_alloc_string [label="jl_gc_alloc_string *"];
jl_gc_alloc [label="jl_gc_alloc *"];
jl_managed_malloc [label="jl_managed_malloc *"]; // #20
jl_gc_pool_alloc;
jl_gc_pool_alloc_outer [fillcolor=lightgreen style=filled label="jl_gc_pool_alloc_outer *"];
jl_gc_big_alloc;

generated_code -> jl_gc_alloc_string;
generated_code -> new_array;
generated_code -> jl_gc_alloc;
generated_code -> jl_gc_big_alloc [color=red];
generated_code -> jl_gc_pool_alloc_outer;
jl_gc_pool_alloc_outer -> jl_gc_pool_alloc;

jl_gc_alloc -> jl_gc_pool_alloc;
jl_gc_alloc -> jl_gc_big_alloc;
new_array -> jl_gc_alloc;
new_array -> jl_managed_malloc;
jl_gc_alloc_string -> jl_gc_pool_alloc;
jl_gc_alloc_string -> jl_gc_big_alloc;
}

</details>

[NHDaly]

My main comment is about trying to find a more informative name for this, like maybe:

• jl_gc_pool_alloc_from_gen
• jl_gc_pool_alloc_from_llvm_gen
• jl_gc_pool_alloc_from_generated...
• jl_gc_pool_alloc_that_will_be_called_from_generated_code... i dunno...

Blech naming is hard

[NHDaly]

Awesome. So, I think this looks great, totally solves the problem, and makes sense! 👍

I do think it'd be good to get a second opinion. Thanks for all the reviews of late, @vchuravy -- would you be able to have a look here too? The PR description explains very well what we did here. ❤️

[vchuravy]

I would prefer keeping the same name here, and renaming the inner internal implementation, which then also shouldn't be exported (and ideally inlined into this function).

Maybe call that one then jl_gc_pool_alloc_impl

[NHDaly]

We talked about inlining it too, but we weren't sure about how to inline it only into this function..

If we mark that one inline, it'll end up inlining into the normal callers of it, though.. So the C functions (indicated in Pete's graph, above) that calls jl_gc_pool_alloc would now call jl_gc_pool_alloc_impl instead, and then it would be inlined.

So it'd become inlined into jl_gc_alloc_ and jl_gc_alloc_string. Maybe that's okay?

Or would you want us to create yet a third separate wrapper function that gets called by those? So we would have three functions:

• jl_gc_pool_alloc_from_generated: called from generated code
• jl_gc_pool_alloc: called from jl_gc_alloc_ and jl_gc_alloc_string
• jl_gc_pool_alloc_impl: called from jl_gc_pool_alloc
  ? Or is that too weird? And the extra inlining is actually fine?

[vilterp]

Closed in favor of JuliaLang#43868 cuz I couldn't change the base to point at JuliaLang/julia