runtime: temporarily store waspi2 memory allocations from cabi_realloc#4897
runtime: temporarily store waspi2 memory allocations from cabi_realloc#4897ydnar wants to merge 2 commits intotinygo-org:devfrom
Conversation
ydnar
requested review from
aykevl,
deadprogram and
dgryski
and removed request for
aykevl
|
I think I have run into a similar problem using In any case, this seems fine to me if it does fix the wasip2 issue as described. @dgryski any comment here? |
|
I ran into a related issue with the wasmimport functions today and have a reproducer. Unfortunately the fix in this PR will not fix that issue, and instead result in a memory leak. Do not merge this. |
We have the same issue for libc malloc/realloc. A simple solution would be to call (I also see that EDIT: See: #4898 |
This is an initial take at solving the interaction between the TinyGo GC and the Component Model allocation scheme (cabi_realloc).
- Do not use make([]byte, ...) to allocate, instead allocate a slice
of pointers. This makes sure the precise GC will scan the contents
of the allocation, since C could very well put pointers in there.
- Simplify the map to use the pointer as the key and the size as the
value, instead of storing the slices directly in the map.
ydnar
force-pushed
the
ydnar/wasmexport-realloc
branch
from
1889b33 to
c8bb418
Compare
3 participants
This is an initial take at solving the interaction between the TinyGo GC and the Component Model allocation scheme (
cabi_realloc).Specifically, when the host calls an exported function with argument(s) that require allocations, these are first allocated in the guest via calls to
cabi_realloc, then these pointer(s) are passed to the function exported withgo:wasmexport.Because these allocated pointers are not stored anywhere in the TinyGo stack or heap, they are subject to immediate collection. This can happen if the host wants to copy a large string into the guest memory, and performs a sequence of
cabi_realloccalls to grow the target memory.The fix is simple: hold onto the pointers allocated by
cabi_reallocuntil the nextwasmexportfunction returns.This logic currently works for reactor modules, where allocations created with
cabi_reallocare held in memory until ago:wasmexportfunction exits. Caveat: when used with a long-running program like the defaultwasi-cliworld, any allocations created viacabi_reallocwill be held forever until funcmainexits.This is intended to fix the problem in bytecodealliance/go-modules#348.