fitzgen (he/him) (May 21 2020 at 19:10): fitzgen (he/him) (May 21 2020 at 19:10):Right now, if you use r32 or r64 without enabling stack maps, then assertions fail. This makes sense if the assumption is that they are always references to GC-managed things.
I'm adding externref support in Wasmtime, and I'm using ref counting, not a tracing gc. The default implementation of cranelift_wasm::TargetEnvironment::reference_type translates externref to r32 or r64 depending on the target's pointer width.
Do folks think it be better to
relax the constraint on r32 and r64 so that they can be used without stack maps, or
override the TargetEnvironment::reference_type method to return i32 or i64 for pointers to reference counted things?
bjorn3 (May 21 2020 at 19:50):How do you implement the incrementing and decrementing of the refcount? If you use r32/r64 as is the refcount will never be changed.
fitzgen (he/him) (May 21 2020 at 19:54):I'm doing that in FuncEnvironment's translate methods to do the ref counting operations when they are stored somewhere permanent (ie a global or table) and maintaining the invariant that on-stack (and in local) references are always the callers responsibility to ensure they are held alive. This way, wasm functions don't need to do ref counting operations at function calls nor when accessing or updating locals.
bjorn3 (May 21 2020 at 19:56):Then option 2 (using i32/i64) makes most sense to me.
fitzgen (he/him) (May 21 2020 at 19:57):Yeah, I jsut started exploring that, and it also turns out that the assertion fails even when I override TargetEnvironment::reference_type to return self.pointer_type(), so there is something else suspicious in addition going on here.
Last updated: Dec 06 2025 at 06:05 UTC