Dynamic Asyncify Data End

[nerfZael]

Asyncify currently has a fixed data end pointer.
It should be a dynamic one that changes based on the built modules ASYNCIFY_STACK_SIZE.

export class AsyncWasmInstance {
 public static requiredExports: readonly string[] = [
 "asyncify_start_unwind",
 "asyncify_stop_unwind",
 "asyncify_start_rewind",
 "asyncify_stop_rewind",
 "asyncify_get_state",
 ];

 private static _dataAddr = 16;
 private static _dataStart = AsyncWasmInstance._dataAddr + 8;
 private static _dataEnd = 24576;

[dOrgJelli]

Two ways I can think of doing this (one more preferred IMO than the other).

Preferred: extract this value from the binary. We're already doing this when trying to determine the initial memory page size here.

We'll need to analyze the wasm binary to find the best way to do this. I'd recommend the following approach:

• build module "foo" twice, with two different ASYNCIFY_STACK_SIZEs
• convert both to WAT
• diff, and see where the stack size is stored (most likely in the "length" property of a global buffer instance)

If we can extract this stack size in a deterministic way with all asyncify-compiled modules, then we should continue with this approach.

Fallback: Inject a getter into the wasm binary upon compilation. Maybe something like _wrap_compiler_config which returns a tuple of (version, config). In the initial implementation, version would be 0x01 and config would be a single value $ASYNCIFY_STACK_SIZE.

[dOrgJelli]

EDIT! before proceeding with the above, we should probably revisit this code here:

javascript-client/packages/asyncify/src/AsyncWasmInstance.ts

Lines 134 to 137 in 9aee0cf

	new Int32Array(memory.buffer, AsyncWasmInstance._dataAddr).set([
	AsyncWasmInstance._dataStart,
	AsyncWasmInstance._dataEnd,
	]);

It could actually be the case that we're overwriting existing values in the wasm module with our hard-coded ones in JS.