bndbsh (Aug 24 2020 at 18:29): bndbsh (Aug 24 2020 at 18:29):is there any reasonable way to check the wasm stack (eg for gc purposes) from the host? it looks like internally wasmtime uses cranelift's StackMap, I think to handle externref gc. but this information is not exposed in the api
one approach I'm thinking of would be to scan the whole native stack, though that seems like overkill. and not sure if there's any guarantee around there being a gc safepoint
fitzgen (he/him) (Aug 24 2020 at 18:54):what are you trying to accomplish?
every call is a safepoint, fwiw
bndbsh (Aug 24 2020 at 20:11):trying to see if the calling wasm code has any references on the stack/in locals to add to gc roots
fitzgen (he/him) (Aug 24 2020 at 21:32):@bndbsh roots for an external-to-Wasmtime GC? i.e. integrating Wasmtime into a JVM and finding JVM objects that have been passed into Wasm and are on the stack?
bndbsh (Aug 24 2020 at 21:38):in this case the memory to be gc'd is wasm linear memory, and the references are i32 offsets into it. but since wasm is not allowed inspect its own stack, i thought it might help to have an external function do the scan via wasmtime APIs
fitzgen (he/him) (Aug 25 2020 at 15:58):Cranelift will only generate stack maps for values whose type is a reference type, not i32s, so I don't think this approach will work out very well.
Instead, I'd suggest maintaining your own shadow stack of gc pointers in the linear memory that you can walk and scan whenever you want.
bndbsh (Aug 26 2020 at 17:31):yeah, that seems to be the most reasonable approach and the one taken by other projects I've looked at. thanks for the pointers
Last updated: Nov 22 2024 at 16:03 UTC