Release process for WasmEdge 0.14.0

[q82419]

Summary

Planned alpha.1 date: 2024/01/05

Planned alpha.2 date: 2024/02/23

Planned alpha.3 date: 2024/03/05

Planned rc.1 date: 2024/03/15

Planned rc.2 date: 2024/03/20

Planned rc.3 date: 2024/03/22

Planned rc.4 date: 2024/04/03

Planned alpha.4 date: TBD

Planned release date: TBD

Features

• [x] WASM serialization
  • #2819
• [x] WebAssembly Typed Function Reference Proposal
  • #2691
  • #3129
• [x] Loader phase of WebAssembly Component Model Proposal
  • #3036
  • #3149
  • #3152
• [x] Preparation of WebAssembly GC Proposal
  • #3094
• [x] WebAssembly GC Proposal
  • #3007
  • #3072
• [x] WebAssembly Exception Handling Proposal
  • #3306

Issues

• [ ] RustLS plugin fail due to the ABI change
  • #3138

Documents

• [x] Update the C API document.

Appendix

No response

[bashor]

@hydai @q82419 WasmEdge 0.14.0-alpha.2 doesn't work on macOS, at least due to a lack of libprotobuf.25.1.0 and libgrpc++.1.60.dylib.

[hydai]

Hi @bashor Thanks for raising this issue; I am working on fix #3242 and will have alpha.3 soon to fix it.

[bashor]

@hydai @q82419 Any ETA for alpha.3? Do you have any plans for EH proposal in 0.14.0?

[hydai]

We have Peace Memorial Day in Taiwan this week, so the alpha.3 will be released next week. The EH proposal is not in 0.14.0; we are going to have 0.14.1 once the EH proposal finishes the implementation.

[bashor]

Good to know! @hydai thank you for the quick reply.

[bashor]

Hi, @hydai! Good news, I managed to run a sample compiled from Kotlin in WasmEdge 0.14.0-rc.1 and print something to the stdout. But it required some tricks to avoid initialization, since otherwise WasmEdge fails with:

segmentation fault  wasmedge --enable-all --reactor  one

[hydai]

Hi @bashor May I have the WASM to debug this issue?

[bashor]

@hydai sure, here it is kotlin-wasm-wasi-example-wasm-wasi.wasm.zip

Following works by running _start, which directly calls wasi APIs

$ wasmedge --enable-all kotlin-wasm-wasi-example-wasm-wasi.wasm    
[2024-03-18 12:02:01.300] [warning] GC proposal is enabled, this is experimental.
[2024-03-18 12:02:01.301] [warning] component model is enabled, this is experimental.
Hi!%  

This fails at startup during initialization, in general, this initialization part is required for Kotlin/Wasm programs:

$ wasmedge --enable-all --reactor kotlin-wasm-wasi-example-wasm-wasi.wasm one
[2024-03-18 12:03:21.796] [warning] GC proposal is enabled, this is experimental.
[2024-03-18 12:03:21.797] [warning] component model is enabled, this is experimental.
zsh: segmentation fault  wasmedge --enable-all --reactor  one

[q82419]

Hi @bashor ,

Thanks for the test file and the steps. The reason is that for the array.new_default instruction, the null reference values lost the type information in the case that the array element type is a reference type. Fixed in the PR #3292 and tested for passing the example above.

$ ./wasmedge --enable-all --reactor kotlin-wasm-wasi-example-wasm-wasi.wasm one
[2024-03-19 17:25:59.328] [warning] GC proposal is enabled, this is experimental.
[2024-03-19 17:25:59.329] [warning] component model is enabled, this is experimental.
1

[bashor]

@q82419 Thanks for the fix! When do you expect it to be available?

[hydai]

@q82419 Let's have rc.2 tmr once #3292 got merged.

@bashor, Would you have more examples to test the GC proposal? We found that the above error is not included in the GC spec tests. We would like to have more examples and tests to verify the GC proposal before we have the official 0.14.0. WDYT?

[bashor]

@hydai Right now, we have only a basic example here.

[bashor]

As soon as we get a build with #3292 we can try to run our compiler tests, but it might be tricky since so far we run tests only on JS + Wasm VMs.

[q82419]

Hi @bashor ,

rc.2 released and welcome to test with it. And also feel free to report if there's bug in GC implementation. Thanks!

[bashor]

@q82419 Thanks! I've checked rc.2 with simple examples, and it works well so far.

[bashor]

Recently I ran a big chunk of compiler tests (7561) with rc.2, and about 90% of them passed.

I see two big groups of tests that failed:

• Tests in the first group failed on unreachable instruction which was generated instead of throw instruction due to the lack of exception handling support.
• Tests in the second group failed due to a problem in our test infra.

Good job! 🙌 Congrats, folks! 🎉

cc @q82419 @hydai @juntao

[hydai]

Thanks @bashor That's such a good news. We are working on the Exception Handling proposal now. We would like to have it in the 0.14.1 soon.

[bashor]

We are working on the Exception Handling proposal now. We would like to have it in the 0.14.1 soon.

@hydai Great! Do you have an approximate timeline for that?

[hydai]

A working PR is here: https://github.com/WasmEdge/WasmEdge/pull/3306 We would like to have it at the end of April or later.

[q82419]

Hi @bashor ,

We planned to back to alpha.4 in these days for adding the exception-handling proposal supporting in 0.14.0 after merging #3306 . Please feel free to test then. Thanks!

[bashor]

@q82419 🔥 Super! Looking forward to it!

[bashor]

@q82419 As I see, you are supporting only the latest version of EH, and I'm wondering if you could support a previous version as well, maybe a limited version w/o rethrow.

Reasoning:

• The previous version of the proposal has been available by default in all browsers for quite a long time now
• In Kotlin, we still use the previous version of the proposal by default and can only switch to the new one once all major VMs support it and most users migrate to those VM versions.
  • Likely, it is the same for other languages using the proposal.

[q82419]

@q82419 As I see, you are supporting only the latest version of EH, and I'm wondering if you could support a previous version as well, maybe a limited version w/o rethrow.

Reasoning:

• The previous version of the proposal has been available by default in all browsers for quite a long time now

• In Kotlin, we still use the previous version of the proposal by default and can only switch to the new one once all major VMs support it and most users migrate to those VM versions.

  • Likely, it is the same for other languages using the proposal.

Sorry that we just updated the latest version (https://github.com/WebAssembly/exception-handling/pull/285) and tuned the performance. The old one still remain on the commit (https://github.com/WasmEdge/WasmEdge/pull/3306/commits/74ad572a72b23c1925731b7cfaa940553f038389), but the performance is not tuned, and still some spec test failed. It will take times if we support the both versions.

cc @hydai

[bashor]

@q82419, any updates on EH and alpha.4?

[q82419]

Hi @bashor ,

I'm working with supporting the legacy exception-handling proposal, which is supported by the toolchain. I think it takes days. After passing the spec tests, we'll have the alpha.4 with the previous version of EH. Thanks!

[bashor]

🤩 Wow! Nice! Thanks for the efforts!

[bashor]

I'm just wondering if alpha.4 will have support for both versions of EH.

[bashor]

Just in case, rethrow is not needed for Kotlin (I've heard it's tricky to support in old EH)

[q82419]

I'm just wondering if alpha.4 will have support for both versions of EH.

Sure, the both version of EH will be supported. We'll remove the legacy one once the proposal entering phase 4, or the toolchain updated.

[q82419]

Just in case, rethrow is not needed for Kotlin (I've heard it's tricky to support in old EH)

In current status, the EH instructions are done except the delegate and rethrow. Thanks for the information, and we'll consider this.