I'm testing out hooking up mmtk to a Cranelift generated program in a minimal example, mainly to learn how it works and figure out how I'm later gonna do it in my actual compiler.
My current understanding is that you retreive the full stackmap information at compile-time from MachBufferFinalized::user_stack_maps and then decide yourself how to re-format that data into your own data structures to be made available at runtime for then invoking the garbage collector with. However; Storing this information directly as-given (&[(CodeOffset, Span, Vec<PointerSize, SpOffset>)]) doesn't seem viable as finding the correct associated offsets from an InstBuilder::get_stack_pointer would require some sort of linear scan at runtime. Is there some "intended" way to use this information?
Here's some half-baked ideas I'm considering.
Put the user_stack_maps data in a global variable. At any location in code where my compiler injects a call to invoke the GC, hardcode an index/slice into the element of the global variable that corresponds to the current function. Make sure this is done in the translation unit that contains the call to GC and not in the stdlib that contains the GC API.
Since the offsets are ordered, perform a binary search at runtime and hope the overhead isn't big enough.
Figure out at compile-time which part of the user_stack_maps is associated with the current function and hardcode the associated stackmap information into the GC callsite directly instead of loading information from a global variable. (this might be tricky as it requires changing functions after already having finalized the MachBuffer?)
Would love some pointers on this, or some clarification on what end-result was invisioned when designing the stackmaps API.
I am planning on trying to add this to the cranelift-examples repository.
@Floppy you can look at what Wasmtime does for inspiration:
Basically, it creates a custom object section with the stack map data in an easily index-able format that doesn't really require parsing at runtime and just does a binary search
hm alright, i'll take a look thanks
Last updated: Jun 01 2026 at 09:49 UTC