wazero: vanhemmat versiot ja versiohistoria

Hi wazero friends! The new release of wazero v1.12.0 has arrived.
This release advances us a few more steps towards Wasm 3.0!
See #2426 (comment) for where we currently stand.
Behavioral changes
- 929e400 Extended Constant Expressions (#2468) @mpoindexter
- bfb20e0 Exception handling (#2489) @evacchi
- 2c14bbf Typed references (#2497) @evacchi
- 8ee2508, a877b1b non-blocking IO on custom files (#2476, #2479) @paralin
Bug fixes
- 2bbd517 Fix fd_prestat_get integer overflow on 32-bit platforms (#2491) @hanxi
- 0bcb5f2 Ensure i32 operations are masked (#2488) @evacchi
- dafe2ca Fix error when attempting to invoke a start function imported from a host module (#2475) @mpoindexter
- f7cf169 Fix error when importing functions which were re-exported (#2463) @mpoindexter
- aa7ebad Don't use compiler when executable mmap is disabled (#2471) @anuraaga

Hi wazero friends! The new release of wazero v1.11.0 has arrived.
This release is a small "break with the past" it the sense that we added one go.mod dependency to wazero: golang.org/x/sys; read the rational for why.
Behavioral changes
- 77db968 Require Go 1.24 (#2448) @ncruces
- fe2e751 Use golang.org/x/sys (#2443) @ncruces
Bug fixes
- 9286448 Update Wasm 2.0 spec tests. (#2458) @ncruces
- 5e7c35e Fix race condition in refCount initialization (#2447) @jackorse
New Contributors
- @jackorse made their first contribution in #2447
Full Changelog: v1.10.1...v1.11.0

wazero 1.9.0 comes with a few bug fixes (#2378, #2365) as well as it is ensured to be compatible with the latest Go 1.24! Enjoy!

This release includes two main things:
- the arm64 bug fix for a huge binary #2346 by @evacchi
- misc OSes supports by @ncruces

Hey, gophers! Do you know what time it is? It is that time of the year again! That time when we all gather together to share our time with friends and family to celebrate ANOTHER AWESOME WAZERO RELEASE!Notably, this release includes the first public experimental release of the long-awaited, highly-requested multi-pass optimizing compiler! Keep reading for more details!A huge thanks to all the contributors, old and new, and always remember that all the developers hang out at the Gophers Slack in the #wazero channel; and if you haven’t already you can star our repo. You know, Santa is making a list, and checking it twice.It’s been a while since v1.5.0, but we promise v1.6.0 was worth the wait! Fun facts about v1.6.0:- This is the best release since the last one.
- This release is 100% richer in holiday cheer. ❄️🎄
- Mulled wine is a fantastic developer productivity boost.
The Optimizing Compiler
Jokes aside, we have a lot to cheer about! The lion share of this release is obviously our brand new optimizing compiler (codename “wazevo”) now available as an experimental feature for arm64 (#1496)!@mathetake led the design and implementation. Work started this summer, and it has evolved in a few iterations over the last months. Initial focus has been on general abstract infrastructure and support to the arm64 instruction set as our first compilation target. @evacchi contributed to the arm64 backend with special focus on the SIMD instructions, and @achille-roussel helped improve the initial register allocator (this was then further evolved and eventually overhauled again by @mathetake). @ncruces contributed with suggestions and testing.We held off a few releases to polish this new compiler and gain more confidence in the implementation. In this first public release, the optimizing compiler is only available for arm64. The journey to supporting amd64 is set to begin soon with @evacchi leading the effort.The new compiler has been, as usual, extensively tested against the Wasm spec, our own unit tests, and against the standard libraries of TinyGo, Go and Zig; and of course it has also been hardened through hours-long fuzzing.You can enable the optimizing compiler by replacing wazero.NewRuntimeConfigCompiler() or wazero.NewRuntimeConfig() with the new experimental API as follows:

- c := wazero.NewRuntimeConfigCompiler()
+ c := opt.NewRuntimeConfigOptimizingCompiler()
- c := wazero.NewRuntimeConfig()
+ c := opt.NewRuntimeConfigOptimizingCompiler()

The CLI is now also exposing an experimental flag -optimizing-compiler:

wazero run -optimizing-compiler myapp.wasm

The optimizing compiler is an experimental feature so we welcome your input. It is also a work in progress: we implemented only a few optimization passes, guiding our choices through testing and benchmarking.It is worth noting that WebAssembly is an interesting beast: since it is a compilation target, most compilers generate pre-optimized output; therefore, some traditional optimization passes may surprisingly only add build-time overhead and produce no observable improvement. However, our work there is far from being done: more optimization passes can be added; we invite you to do your experiments and bring your own suggestions. For instance, among others, we currently implement forms of dead-code elimination, and bounds-checking eliminations.In your experiments, you should also expect the CompileModule phase to take a while longer than the old compiler: the difference may be noticeable with large modules; but you can still cache the result, so you can pay this cost only once. The good news is that, in our tests, the run-time should always visibly improve. Interestingly enough, there are also some cases where both compile-time and run-time have improved: this might be the case when the input module is not pre-optimized, and the dead-code elimination procedures kick in.For instance, the Zig standard library is about 2x quicker to compile and 4x faster to run than the old compiler.