bugfix: Tighten up memory model. #417
Conversation
|
Sorry about the various changes to the comments; those were done by |
Fixes wasmerio#415 As documented in wasmerio#415, the memory mode exposed by wasmer-go is error prone and hard to use. Introduce a `CPtrBase[T]` helper struct to attempt to surface errors often and early. The `CPtrBase` is meant to store a CGo pointer. Then, through conditional compilation, a debug implementation, enabled via `-tags memcheck` tag, is used, which adds expensive pointer access checks as well as forces calls to `runtime.GC()` whenever underlying pointer accessed. These access are very slow -- however, they cause almost immediate crashes to surface in tests. It's possible that some issues still remain; The fixes were applied in order to ensure that the tests pass 5000 times. Beyond that, there could still be remaining issues.
|
@syrusakbary do you think this approach makes sense? |
|
@ayys @syrusakbary : not sure who can review this; can you recommend somebody if you can't? |
|
Hi! I work for Wasmer as SRE and the primary focus of Wasmer is elsewhere (getting the Go SDK up and running is not a prio right now). But! I'm personally a gopher, and decided to take on wasmer-go as a pet project (hobby). I more on the cloudy side, don't know that much about compilers, C etc, but do know CI/CD and golang at large. So, I just merged this pr which cleans up the project quite a bit and adds code a QA pipeline with gofumpt, staticcheck and other goodies. Could you please rebase on master? The conflicts are most likely the formatted files, and I also fixed a few staticcheck issues. Once rebased, I'll enable workflow runs for you. Then I'll review this PR more properly and we can take it from there Thanks for your contribution, it's much appreciated! |
Fixes #415
As documented in #415, the memory mode exposed by wasmer-go is error prone and hard to use.
Introduce a
CPtrBase[T]helper struct to attempt to surface errors often and early. TheCPtrBaseis meant to store a CGo pointer. Then, through conditional compilation, a debug implementation, enabled via-tags memchecktag, is used, which adds expensive pointer access checks as well as forces calls toruntime.GC()whenever underlying pointer accessed. These access are very slow -- however, they cause almost immediate crashes to surface in tests.It's possible that some issues still remain;
The fixes were applied in order to ensure that the tests pass 5000 times. Beyond that, there could still be remaining issues.