* runtime: run syscall/js finalizers on wasm without a manual GC
* runtime: address review feedback on finalizer idle GC
* runtime: clear a finished task's args pointer so its arguments are collectable
* runtime: skip the finalizer scan with a per-block registration bit
* runtime: guard the finalizer registration bitmap with gcLock
* testdata: cover finalizer invariants on every scheduler
* main_test: limit the finalizer scheduler variants to linux and darwin
* testdata: wait for the finalizer queue to drain before asserting
* testdata: make the finalizer counters atomic and wait for a known drain count
* runtime: add finalizer bookkeeping asserts under runtime_asserts
* runtime: address finalizer GC review feedback
* testdata: strengthen blocked stack finalizer test
* runtime: fix finalizer cleanup edge cases
* runtime: decouple wasm export scheduling from finalizers
* runtime: avoid redundant wakeups for re-entrant wasm exports
* runtime: simplify finalizer comments
This changes the order for initialization of the random number
seed generation on wasm platforms until after the heap has been
initialized. Should fix#5198
Signed-off-by: deadprogram <ron@hybridgroup.com>
The reason is that allocating without a heap is usually more visible
than using an uninitialized random generator which is subtle and may
lead to security vulnerabilities.
Based on suggestion from @eliasnaur
Signed-off-by: deadprogram <ron@hybridgroup.com>
older behavior for wasi modules to not return an exit code as if they were reactors.
See #4726 for some details on what this is intended to address.
Signed-off-by: deadprogram <ron@hybridgroup.com>
This ensures:
1. The xorshift state is initialized during interp.
2. The xorshift state gets initialized to a real random number on
hardware that supports it at runtime.
This fixes a big binary size regression from the previous commit. It's
still not perfect: most programs increase binary size by a few bytes.
But it's not nearly as bad as before.
This adds support for //go:wasmexport with `-target=wasm` (in the
browser). This follows the //go:wasmexport proposal, meaning that
blocking functions are not allowed.
Both `-buildmode=default` and `-buildmode=c-shared` are supported. The
latter allows calling exported functions after `go.run()` has returned.
This adds support for the `//go:wasmexport` pragma as proposed here:
https://github.com/golang/go/issues/65199
It is currently implemented only for wasip1 and wasm-unknown, but it is
certainly possible to extend it to other targets like GOOS=js and
wasip2.
Felipe Gené
deadprogram
Ayke van Laethem
Randy Reddig