Wasmtime GitHub notifications bot (Jul 20 2022 at 16:41): Wasmtime GitHub notifications bot (Jul 20 2022 at 16:41):alexcrichton commented on issue #4479:
As-is this document is a work in progress and I would like to gather feedback from others about their thoughts on this classification. My hope is that most of the guidelines here are pretty uncontroversial, but if there are points of contention then I will close this and reopen it as an RFC for a more official venue of discussion.
I also plan on talking about this in the upcoming days at the Cranelift and Wasmtime weekly meetings to cast a wide net for getting interest in this.
Wasmtime GitHub notifications bot (Jul 22 2022 at 18:18):cfallin commented on issue #4479:
This is a great overall idea, as I mentioned in the Wasmtime biweekly -- thanks for putting this together @alexcrichton!
I had a few additional thoughts on the sorts of things that could be tiered, both related to Cranelift. Basically any large feature or piece of functionality could in theory be assigned a tier, and two that come to mind are:
- Support for Cranelift features not exercised by Wasmtime. While we want to maintain wide support as much as possible, in practice the parts of Cranelift that are exercised by Wasmtime get a lot more testing and are more solid as a result. The set of features/instructions/types used by
cranelift-wasmis also significantly smaller than the whole theoretical range of programs that can be expressed in CLIF. At least in the following dimensions we can make this distinction:
- Instructions (CLIF opcodes);
- Value types (
I32/I64/F32/F64/128-bit vectors, vs. everything else -- narrow and wide types, bools, etc.);- Other calling conventions (e.g., SpiderMonkey/Baldrdash);
- Other "code model" settings, such as relocation restrictions, etc;
- Other Cranelift settings than what is configured by Wasmtime in general.
I would argue that the above (i.e., non-Wasmtime uses of Cranelift) should be listed as tier 3, in order to capture the de-facto situation we have today. To graduate from tier 3, we would need someone working on Cranelift fulltime whose focus is these other use-cases.
I also think that debug support is already de-facto tier 3, and should be listed as such. Partly this is because no one currently on the project fully understands the code, and partly this is because there are some lingering issues or shortcomings. We've recently seen debug support as sort of best-effort, in the sense that we try to keep it working for the tests (I put in a few weeks of effort specifically on regalloc2 and the new-backend migrations for this) but we don't have the developer time to make and support strong guarantees. To graduate from tier 3, we would need someone who deeply understands DWARF and debug infrastructure to overhaul the code, improve its robustness, then continue to support it.
And finally to write down something I said at the meeting here: I think it would be really useful to list "what is needed to graduate" alongside features/platforms at lower tiers. This serves both to capture some rationale, and to motivate: if I (as a potential contributor) see that all a given feature needs to be tier-1 and on by default is some more fuzzing, and I want that feature, maybe I will jump in and help. I wrote down some "to graduate" conditions above as examples. In particular I think some of the items in your list are pretty close: e.g. aarch64 really just needs fuzzing on real hardware to be tier-1 supported, if I understand correctly.
Wasmtime GitHub notifications bot (Jul 22 2022 at 18:18):cfallin edited a comment on issue #4479:
This is a great overall idea, as I mentioned in the Wasmtime biweekly -- thanks for putting this together @alexcrichton!
I had a few additional thoughts on the sorts of things that could be tiered, both related to Cranelift. Basically any large feature or piece of functionality could in theory be assigned a tier, and two that come to mind are:
Support for Cranelift features not exercised by Wasmtime. While we want to maintain wide support as much as possible, in practice the parts of Cranelift that are exercised by Wasmtime get a lot more testing and are more solid as a result. The set of features/instructions/types used by
cranelift-wasmis also significantly smaller than the whole theoretical range of programs that can be expressed in CLIF. At least in the following dimensions we can make this distinction:
- Instructions (CLIF opcodes);
- Value types (
I32/I64/F32/F64/128-bit vectors, vs. everything else -- narrow and wide types, bools, etc.);- Other calling conventions (e.g., SpiderMonkey/Baldrdash);
- Other "code model" settings, such as relocation restrictions, etc;
- Other Cranelift settings than what is configured by Wasmtime in general.
I would argue that the above (i.e., non-Wasmtime uses of Cranelift) should be listed as tier 3, in order to capture the de-facto situation we have today. To graduate from tier 3, we would need someone working on Cranelift fulltime whose focus is these other use-cases.
I also think that debug support is already de-facto tier 3, and should be listed as such. Partly this is because no one currently on the project fully understands the code, and partly this is because there are some lingering issues or shortcomings. We've recently seen debug support as sort of best-effort, in the sense that we try to keep it working for the tests (I put in a few weeks of effort specifically on regalloc2 and the new-backend migrations for this) but we don't have the developer time to make and support strong guarantees. To graduate from tier 3, we would need someone who deeply understands DWARF and debug infrastructure to overhaul the code, improve its robustness, then continue to support it.
And finally to write down something I said at the meeting here: I think it would be really useful to list "what is needed to graduate" alongside features/platforms at lower tiers. This serves both to capture some rationale, and to motivate: if I (as a potential contributor) see that all a given feature needs to be tier-1 and on by default is some more fuzzing, and I want that feature, maybe I will jump in and help. I wrote down some "to graduate" conditions above as examples. In particular I think some of the items in your list are pretty close: e.g. aarch64 really just needs fuzzing on real hardware to be tier-1 supported, if I understand correctly.
Wasmtime GitHub notifications bot (Jul 25 2022 at 17:46):alexcrichton commented on issue #4479:
Discussion of this in the Wasmtime/Cranelift meetings felt positive about the various bits here, so I'd like to give some more time in case anyone has feedback, otherwise I will merge later this week.
Wasmtime GitHub notifications bot (Jul 29 2022 at 14:17):alexcrichton commented on issue #4479:
Ok there hasn't been any further discussion of this so I'm going to queue up its merge. PRs and tweaks over time are of course welcome though!
Last updated: Oct 23 2024 at 20:03 UTC