Erik Rose

@cfallin Quoting from https://github.com/bytecodealliance/wasmtime/pull/12101#issuecomment-3598788048 to continue discussion on a live ticket and tie these two together… > @erikrose there's a potential epoch-yield mechanism that requires no dead loads/stores at all...

@cfallin Clear as a bell; thank you!

`wasm-reduce` yields this shorter version which still crashes. I've hand-stripped the `producers` and `target_features` sections off. ```wasm (module (type (;0;) (func)) (type (;1;) (func (param i32 i32) (result i32))) (import...

`wasm-reduce` is a bit aggressive and randomly mutates instructions. In our case, where the `State` lives in wasm linear memory, it can quite possibly land on an otherwise unrelated program...

The adapter [will happily use `cabi_realloc()`](https://github.com/fastly/Viceroy/blob/8e2e02efb3707d40e08663f4c5d025b1d03fe441/crates/adapter/src/lib.rs#L1594), if it can find it, at adaption time to carve out a chunk of linear memory for itself. As a test, Dan and I...

Solutions I considered: 1. Have the adapter add a `cabi_realloc()` which calls `malloc()`, which allocates a region of memory and hangs onto it from the GC's point of view. Pro:...

I need to rejigger this so it tests for the TinyGo-ness of the adapted module, not the adapter.

The above is messy, messy, messy, but it's a working PoC. Now to clean it up…

> Can you detail a bit more here why this is necessary? Absolutely! Basically, we would like to run existing TinyGo-compiled modules as components. So, while an upstream fix would...

Tests are on the way! I had hoped to have them laid in before anyone got around to reviewing, but they proved trickier than expected, and my attention was divided....