Why does runtime dispatch allocate when the return type is inferred?

Internals & Design
,
6

The jl_value_t struct is the name for a block of memory owned by the Julia Garbage Collector, representing the data associated with a Julia object in memory. Absent any type information, it is simply an opaque pointer:

typedef struct jl_value_t* jl_pvalue_t;

Each jl_value_t struct is contained in a jl_typetag_t struct that contains metadata information about the Julia object, such as its type and garbage collector (gc) reachability

That seems to explain why the expected metadata doesn’t show up in memory allocation measurements, like say a Vector{Number}, though it’s still not clear to me whether heterogeneous collections point to the jl_typetag_t or just the jl_value_t for the necessary runtime type information. The text seems to imply the latter, but if so, what uses the metadata?

It does at least make it more apparent that boxes are implemented to be GC-tracked, it’s not just a pointer to anywhere and isn’t a language-level thing that could undergo heap-to-stack optimizations. It’s at least acknowledged to not be strictly necessary for runtime dispatch, which is something FunctionWrappers also demonstrates. I went through the trouble of making this topic because FunctionWrapper’s function pointer magic doesn’t respond to method invalidations well even if I try the internal reinit_wrapper, so Returns{R}(f) would be neater if runtime dispatch can load and write unboxed inputs and outputs.