Stream: cranelift

Topic: r32 and r64 types: always GC'd?


view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip bjorn3 (May 21 2020 at 19:56):

Then option 2 (using i32/i64) makes most sense to me.

view this post on Zulip 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 23 2024 at 12:05 UTC