Releases: wasilibs/nottinygc
v0.7.1
v0.7.0
This is a very important release for Envoy users and it is strongly recommended to upgrade.
Quick upgrade notes: If you use the library in an Envoy plugin, add nottinygc_envoy to your build tags and remove any stub of sched_yield you may have.
We learned that Envoy will call the malloc function implemented by this library expecting it to be freed by the Wasm plugin. While this coincidentally works fine for TinyGo's implementation of malloc, which is implemented using the Go heap which is garbage collected automatically, nottinygc users would have all such invocations leak memory because the memory is allocated in the C heap which is not automatically cleared, and proxy-wasm-go-sdk does not clear manually (malloc is opaque to it so it would have no real way of doing so). Envoy has additionally previously had issues with it's WASI implementation - given the common usage of this library in Envoy plugins, we have added the nottinygc_envoy build tag to add workarounds for both. It prevents malloc from being exported, allowing Envoy to use proxy-wasm-go-sdk's allocation method instead, and enables the WASI workaround.
Essentially all Envoy plugins using this library are likely leaking significant memory, and this should finally have been fixed. Special thanks to @johnlanni for pointing out the issue within Envoy's source code itself, it came as a big surprise.
In addition, we now use _ignore_off_page allocation methods of bdwgc for large allocations as recommended by that library. This has been shown to help reduce false positives even further from adding typed allocations.
Finally, apologies for the version churn, there have been many releases in a short amount of time, which is never a good thing for users. If you see it and feel the library is not stable, your assessment is correct - the reality is we do not have a large test corpus of projects using it, up until now relying on just coraza-proxy-wasm. Thanks to user reports with real code, we have been able to fix significant bugs recently, and we will continue to do so as we find issues, this being a community project. As real usage goes up, we hope things will stabilize over time, recently we have luckily made some significant milestones. Thanks for help and understanding.
New Contributors
- @johnlanni made their first contribution in #33
Full Changelog: v0.6.0...v0.7.0
Contributors
Assets 2
v0.6.0
This releases fixes a major issue introduced with v0.5.1 for precise GC. It is recommended to update to reduce the chance of sporadic issues with GC.
In addition, precise GC has been implemented for larger objects too in addition to smaller ones. The real-world impact of this change should be minor as most objects are not large - for coraza-proxy-wasm, this only affects two allocations in the entire lifetime of the plugin.
Full Changelog: v0.5.1...v0.6.0
v0.5.1
This small patch suppresses warning logs as bdwgc recommends for release builds. GC_STATS=1 environment variable can be set to see the logs with other information.
Full Changelog: v0.5.0...v0.5.1
v0.5.0
v0.5.0 is a significant release which implements precise GC for small object types. Precise GC, as opposed to conservative GC, takes into account type information and can ignore memory that cannot be a pointer, even if the memory "looks like a pointer". Because purely conservative GCs must look at every value in memory for whether they look like a pointer, they can have false positives. In many normal applications using conservative GCs, this is not an issue because 64-bit memory space makes the likelihood of random data matching a memory address to be very low, but WebAssembly is limited to 32-bit memory space, and the likelihood is relatively high. We noticed real applications having memory issues when embedding large files of random-like data (or even just a geo-IP database).
Now, for small objects (up to ~96 bytes), the GC will precisely mark them, only looking at locations that are known to be pointers. This is the object type itself, meaning arrays of objects are also handled precisely. Notably, byte arrays, which have no pointers by their nature, are now handled precisely and will not cause false positives - this should notably impact the case of embedding files. In practice, for the simplistic string allocation benchmark we run in CI, while difficult to compare across different machine types, we are seeing about 3x speedup reflecting that much less memory has to be visited by the GC as it recognizes the strings as pointerless. This means the benchmark probably needs to be updated in the future with more real-world allocation patterns but general application performance should improve somewhat with this change.
Full Changelog: v0.4.0...v0.5.0
v0.4.0
v0.4.0 updates the required TinyGo to 0.28+. If you were using it before with the nottinygc_finalizer build tag, it is safe to remove that tag now.
Additionally, malloc and free are now exposed by default to match the behavior of TinyGo. Note that TinyGo may change this behavior in the future, in which case this library would likely be changed to match it.
Full Changelog: v0.3.0...v0.4.0
v0.3.0
This release changes the behavior of compilation when not configured correctly - correct builds will be unaffected. Previously when TinyGo flags were not configured correctly, a cryptic duplicate symbols was printed during compilation, but now the build will succeed while an error message describing the needed flags and documentation will be printed on startup instead.
Full Changelog: v0.2.0...v0.3.0
v0.2.0
IMPORTANT: the LICENSE file was omitted in this repository for the v0.1.0 release. The intention was to publish with MIT license but this was erroneously left out earlier. It is recommended to update quickly to avoid any potential licensing complications - sorry for the trouble.
What's Changed
- Fix MemStats.Sys does not include GC heap by @anuraaga in #4
- Implement SetFinalizer for latest tinygo dev by @anuraaga in #5
Full Changelog: v0.1.0...v0.2.0
Contributors
Assets 2
v0.1.0
Welcome to nottinygc, a replacement allocator for TinyGo targetting WASI.
There is no code API in this package, however it relies on experimental support for custom GC in TinyGo. We will probably wait a couple of TinyGo versions to see how the mechanism fairs before marking a v1.0.0 release.
This project is made possible by these notable dependencies that deserve many thanks. Notably, both of the embedded libraries were very open and friendly in accepting some changes to allow building for WASI, enabling this project to exist.