Bump github.com/tetratelabs/wazero from 1.6.0 to 1.7.1

[dependabot]

Bumps github.com/tetratelabs/wazero from 1.6.0 to 1.7.1.

Release notes

Sourced from github.com/tetratelabs/wazero's releases.

v1.7.1

Hiya folks, time to celebrate the new wazero release again! The last release 1.7.0 was such a blast so this new 1.7.1 is a little bit boring compared to it, but it still has some niceties!

This patch release has basically two major things: various bug fixes and experimental memory allocation API!

Bug fixes

Since the release of 1.7.0, several community members (@​jerbob92, @​anuraaga and @​davidmdm) tried the new optimizing compiler and reported some bugs. @​mathetake and @​evacchi worked on the fix and all the reported bugs were removed. Notably, the arm64 compiler has become more robust against huge binaries like the ones produced by the Go official compiler, in addition to a corner case in the bounds check elimination optimization pass applied to both arm64 and amd64.

Experimental Memory Allocator API

The experimental Memory Allocator API has been added to our experimental friends by @​ncruces in collaboration with @​achille-roussel. This allows you to control how to allocate the linear memory of Wasm instance. For instance, you can use a memory mapped buffer as a Wasm linear memory. This is highly advanced feature hence requires a lot of detailed knowledge on how Wasm module works. If this is something interesting to you, we highly recommend to talk to @​ncruces who is an expert in here ;)

Other Contributions

• it is now possible to successfully build wazero with TinyGo compiler thanks to the contributions by @​deadprogram and @​orsinium
• @​ncruces helped clean up the dead codes and experimental packages.

v1.7.0

Welcome to wazero 1.7: the release that upgrades like a minor, but feels like a major!

It's finally time for the long-awaited, final release of our brand new optimizing compiler. This is such a big deal that we are celebrating it at [Wasm I/O 2024][wasmio] with another round of wonderful lightning talks from wazero users [like we did in 2023][wazero1]. In fact, even this release is being tagged during the event! Stay tuned on our usual channels to see the recording:

• Follow the [#wazero hashtag on Twitter][twitter]
• Join the [#wazero channel on the Gophers Slack][gophers]

wazero optimizes machine code compiled from wasm

Translating Wasm bytecode into machine code can take multiple forms. An optimizing compiler performs multiple nontrivial transformations on the input code, ultimately producing more efficient ("optimized") code.

In 1.7 we replaced our internal wasm compiler with an optimizing one. This means it is a drop-in: you don’t need to do anything to use it. If interested in compiler design, please read [the docs][wazevo-docs], contributed by @​evacchi.

As for performance improvements, we have come to expect a run-time boost ranging from 10% to even 60%, with 30-40% being the average. Notably:

• @​ncruces' fork of [coremark][coremark] shows an improved score of 15265 vs 9591, i.e. about +60% on arm64 (Apple M1 Pro)
• [mercari/grpc-federation][mercari] improvements between 4-10% on their Wasm extensions to the [Common Extension Language][cel]
• [kubernetes-sigs/kube-scheduler-wasm-extension][k8s-sched] sees an average of >40% decrease on schedule lifecycle overhead
• @​achille-roussel [contributed some numbers][achille-slack] on the Go standard library (GOOS=wasip1) showing at least 30% improvements on the syscall, compress/flate (gzip) and encoding/json packages, with peaks of 60% (especially in data throughput).

While a major improvement, we decided against calling this version 2.0. If we did, we would cause library dependency lockups due to go imports needing a ‘/v2’. We take backwards compatibility seriously, so couldn’t do that to you!

As usual, @​mathetake owns the lionshare of the contributions, with @​evacchi helping along the way, especially on the new amd64 backend. Notably, @​achille-roussel also contributed a performance improvement to the compiler (#2026) and @​ncruces helped in many ways with testing and verifying the implementation, validating (among other things) against his library [go-sqlite3][go-sqlite3].

Note: an optimizing compiler does more work, so it takes longer. Production use of wazero should always compile wasm during initialization to avoid slowing down function runtime.

Experimental: Wasm Threads Spec

The Wasm Threads spec introduces instructions to explicitly share memory between modules, and new operations for atomic memory access. Compilers may use this feature for concurrent threads of execution. For instance @​anuraaga’s [Go ports of protoc plugins][protoc] needed atomic instruction support to compile to Wasm.

1.7 concludes a long journey started with @​anuraaga's first PR #1899 and continued with @​mathetake occasionally tag-teaming, especially to support in the new compiler; @​ncruces assisted with reviewing.

... (truncated)

Commits

• 55f21b8 experimental: custom memory allocator API tweaks (#2186)
• e9bea55 Updates CODEOWNERS (#2185)
• a3d0d96 Cleanups ctxkey package (#2184)
• 378956d compiler(arm64): fixes B.cond offset limits (#2183)
• a0fbb18 experimental: configure custom memory allocator (#2177)
• 891e470 compiler(arm64): fixes overflow in huge executable relocations (#2181)
• f31be30 Fix WithSnapshotter doc to reference non-deprecated method (#2180)
• c6a907b experimental: cleanup context keys (#2175)
• 59faf80 threads: remove dead code (#2176)
• 775330a Reverts the public Memory.Pages API (#2174)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)