Stream: git-wasmtime

Topic: wasmtime / issue #3941 Temporarily delete the module link...

Wasmtime GitHub notifications bot (Mar 17 2022 at 18:25):

alexcrichton opened issue #3941:

This was discussed in today's Wasmtime meeting but I wanted to open an issue here to get feedback on this as well. In the near future I hope to start implementing the component model inside of Wasmtime which will be a significant step up from the existing module linking implementation that we have today. Previously when implementing the component model in the wasm-tools repository we decided that this development work would happen on a component-model branch and eventually we'd merge that back into main. The main reason for doing this was to ensure that the module linking implementation in Wasmtime could continue to live on.

This immediately creates an issue for Wasmtime, however, in landing the component model implementation. Primarily there are no crates.io-crates to use in Wasmtime for the wasm-tools crates to work with the component model. Additionally Wasmtime as a project seems much more likely to have "big changes" in the time it takes to implement the component model which can make merging a component-model branch back into main extra-hard.

For these reasons my proposal in today's meeting was that we merge the component-model branch of wasm-tools into the main branch. In doing so we would then "schedule" the deletion of the module linking implementation in Wasmtime for the next update of the wasm-tools crates. This would then over time be replaced with an implementation of the component model as I fill it out.

I'd like to get others' feedback on this because it would entail deleting an active, but unstable, feature of Wasmtime -- the module linking proposal. In doing some planning of the component model I don't think much of the existing module linking implementation is likely to be used line-for-line as-is right now. Most of the parsing/validation/types/etc are significantly different and some design decisions that affected the module linking implementation are not present with the component model (such as core wasm modules are only at leaf nodes, not any node).

This means the two primary users of the module linking proposal at this time, wizer and the spidermonkey integration in wit-bindgen, would need to be disabled temporarily while the component model is implemented.

cc @peterhuene and @tschneidereit I'm particularly interested in y'all's thoughts on this.

Wasmtime GitHub notifications bot (Mar 17 2022 at 18:25):

alexcrichton labeled issue #3941:

This was discussed in today's Wasmtime meeting but I wanted to open an issue here to get feedback on this as well. In the near future I hope to start implementing the component model inside of Wasmtime which will be a significant step up from the existing module linking implementation that we have today. Previously when implementing the component model in the wasm-tools repository we decided that this development work would happen on a component-model branch and eventually we'd merge that back into main. The main reason for doing this was to ensure that the module linking implementation in Wasmtime could continue to live on.

This immediately creates an issue for Wasmtime, however, in landing the component model implementation. Primarily there are no crates.io-crates to use in Wasmtime for the wasm-tools crates to work with the component model. Additionally Wasmtime as a project seems much more likely to have "big changes" in the time it takes to implement the component model which can make merging a component-model branch back into main extra-hard.

For these reasons my proposal in today's meeting was that we merge the component-model branch of wasm-tools into the main branch. In doing so we would then "schedule" the deletion of the module linking implementation in Wasmtime for the next update of the wasm-tools crates. This would then over time be replaced with an implementation of the component model as I fill it out.

I'd like to get others' feedback on this because it would entail deleting an active, but unstable, feature of Wasmtime -- the module linking proposal. In doing some planning of the component model I don't think much of the existing module linking implementation is likely to be used line-for-line as-is right now. Most of the parsing/validation/types/etc are significantly different and some design decisions that affected the module linking implementation are not present with the component model (such as core wasm modules are only at leaf nodes, not any node).

This means the two primary users of the module linking proposal at this time, wizer and the spidermonkey integration in wit-bindgen, would need to be disabled temporarily while the component model is implemented.

cc @peterhuene and @tschneidereit I'm particularly interested in y'all's thoughts on this.

Wasmtime GitHub notifications bot (Mar 17 2022 at 19:10):

peterhuene commented on issue #3941:

Would the merge of component-model into main be gated on the inclusion of updates to wast and wasm-smith so that we can have better confidence in the tools' implementations via tests and fuzzing?

So I'm on the same page, when you say "disabled" with regards to wizer, does that mean just deleting the existing module linking implementation in that tool? There are obviously important dependencies on wizer that aren't using module linking, so I want to ensure we don't break those users.

I'm less concerned about wit-bindgen-spidermonkey since it's not on any critical paths (yet) and the work to update it isn't predicated on the implementation in wasmtime as it should have what it needs today to start encoding components, although it'd likely benefit from work I'm doing right now on wit-component to encode wit interface definitions.

Regarding wasmlink, which also has dependency on the module linking proposal, I think that we should fully deprecate and/or remove that tool as it's entirely unnecessary now. It's great for demos, but linking two core modules together and generating adapter functions in wasm isn't needed as the component model implementation moves forward.

Wasmtime GitHub notifications bot (Mar 17 2022 at 19:11):

peterhuene edited a comment on issue #3941:

Would the merge of component-model into main be gated on the inclusion of updates to wast and wasm-smith so that we can have better confidence in the tools' implementations via tests and fuzzing?

So I'm on the same page, when you say "disabled" with regards to wizer, does that mean just deleting the existing module linking implementation in that tool? There are obviously important dependencies on wizer that aren't using module linking, so I want to ensure we don't break those users.

I'm less concerned about wit-bindgen-spidermonkey since it's not on any critical paths (yet) and the work to update it isn't predicated on the implementation in wasmtime as it should have what it needs today to start encoding components, although it'd likely benefit from work I'm doing right now on wit-component to encode wit interface definitions and create components from core modules.

Regarding wasmlink, which also has dependency on the module linking proposal, I think that we should fully deprecate and/or remove that tool as it's entirely unnecessary now. It's great for demos, but linking two core modules together and generating adapter functions in wasm isn't needed as the component model implementation moves forward.

Wasmtime GitHub notifications bot (Mar 17 2022 at 22:39):

alexcrichton commented on issue #3941:

I think we'd need wast/wasm-smith/etc to call the feature complete, but I'm don't think we'd gate the merge to main on them. Basically I think we should consider all module-linking-using things as "dead code walking" which will be deleted as soon as its convenient and otherwise the component model is a work-in-progress proposal which has varying degrees of support in our tooling until everything is finished (which will take some time). That being said though writing tests is gonna be hard without wast.

For disabling I mostly just mean either disabling the tests or otherwise deleting the relevant code. Where it makes sense I think the code can be kept to be transformed to work with the component model but otherwise if the code isn't too applicable to the component model I think it's fine to delete (which is where I believe Wasmtime itself sits)

Also sorry I forgot about wasmlink! I agree on the conclusions though.

Wasmtime GitHub notifications bot (Mar 23 2022 at 19:57):

alexcrichton closed issue #3941:

This was discussed in today's Wasmtime meeting but I wanted to open an issue here to get feedback on this as well. In the near future I hope to start implementing the component model inside of Wasmtime which will be a significant step up from the existing module linking implementation that we have today. Previously when implementing the component model in the wasm-tools repository we decided that this development work would happen on a component-model branch and eventually we'd merge that back into main. The main reason for doing this was to ensure that the module linking implementation in Wasmtime could continue to live on.

This immediately creates an issue for Wasmtime, however, in landing the component model implementation. Primarily there are no crates.io-crates to use in Wasmtime for the wasm-tools crates to work with the component model. Additionally Wasmtime as a project seems much more likely to have "big changes" in the time it takes to implement the component model which can make merging a component-model branch back into main extra-hard.

For these reasons my proposal in today's meeting was that we merge the component-model branch of wasm-tools into the main branch. In doing so we would then "schedule" the deletion of the module linking implementation in Wasmtime for the next update of the wasm-tools crates. This would then over time be replaced with an implementation of the component model as I fill it out.

I'd like to get others' feedback on this because it would entail deleting an active, but unstable, feature of Wasmtime -- the module linking proposal. In doing some planning of the component model I don't think much of the existing module linking implementation is likely to be used line-for-line as-is right now. Most of the parsing/validation/types/etc are significantly different and some design decisions that affected the module linking implementation are not present with the component model (such as core wasm modules are only at leaf nodes, not any node).

This means the two primary users of the module linking proposal at this time, wizer and the spidermonkey integration in wit-bindgen, would need to be disabled temporarily while the component model is implemented.

cc @peterhuene and @tschneidereit I'm particularly interested in y'all's thoughts on this.

Wasmtime GitHub notifications bot (Mar 28 2022 at 19:24):

saulecabrera commented on issue #3941:

I have a question regarding this change: is it safe to assume that moving forward, while the component model changes land, any security/critical fixes will be ported to the last version of wasmtime supporting module linking? For context, at Shopify we have a couple of production use-cases using module linking in its current state and we were wondering about this. I hoping to get some light on this question to determine what are our options here; given the complexity of the changes related to the component model, my assumptions are that these changes might take a while to land but also that other important fixes might land too in the meantime. Any insight on this is appreciated!

Wasmtime GitHub notifications bot (Mar 28 2022 at 21:51):

alexcrichton commented on issue #3941:

With our current release process since module linking was never on-by-default we actually wouldn't have prior made backports for security fixes, they'd just have gone in as usual and get released with the next major version. In that sense we don't currently have plans to backport any module linking fixes.

That being said the decision to remove module linking was largely under the pretext that we didn't know of any active users and it wouldn't be too much of a burden for smaller uses like wit-bindgen and wizer to pause testing of module linking temporarily. You're right that it will take some time to implement the component model to get it to the same level of fidelity of support that module linking had.

If y'all are using module linking internally though and find it difficult to move away would you be up for attending a Wasmtime meeting to discuss your use case? If not a one-off call would also be fine. It's definitely not intended that this would cause too much churn!

Wasmtime GitHub notifications bot (Mar 28 2022 at 22:40):

saulecabrera edited a comment on issue #3941:

I have a question regarding this change: is it safe to assume that moving forward, while the component model changes land, any security/critical fixes will be ported to the last version of wasmtime supporting module linking? For context, at Shopify we have a couple of production use-cases using module linking in its current state and we were wondering about this. I'm hoping to get some light on this question to determine what are our options here; given the complexity of the changes related to the component model, my assumptions are that these changes might take a while to land but also that other important fixes might land too in the meantime. Any insight on this is appreciated!

Wasmtime GitHub notifications bot (Mar 28 2022 at 23:33):

saulecabrera commented on issue #3941:

@alexcrichton thanks for all the details!

If y'all are using module linking internally though and find it difficult to move away would you be up for attending a Wasmtime meeting to discuss your use case? If not a one-off call would also be fine.

I'm definitely interested in joining the meetings, unfortunately I have a small conflict this week, so a one-off call works best this week.

Last updated: Nov 22 2024 at 16:03 UTC