Lowering Asyncify overhead

[iliakan]

Hello,

Thank you for the great project!

Did I get it right that Asyncify must instrument all WASM functions, constituting the call chain from the top to the one that needs to work asynchronously?

Only these functions, or anything else?

I just tried to build emcc -sASYNCIFY, and the .wasm size grew about +70%, kind of too much, so figuring out how to lessen the impact.

[kripken]

Looks like a duplicate of #5494 ? Let's continue the discussion there in one place.

[iliakan]

Thank you for the response. I closed the issue, because maybe I'm just misunderstanding the situation.

Hopefully, after our discussion I'll be able to send a PR to docs, to make them easier to understand (are they in github as well?).

What is an indirect call?
Is it call by a pointer, such as cmd->foo(a, b), where foo is a function pointer int (*foo)(int, int)?
Or something else?

[kripken]

Yes, an indirect call in C is a call by a function pointer. In C++ it can also be a virtual function call in a class. The problem is that virtual calls can go to many possible places, and where is determined only at runtime, so the asyncify analysis must include all the possible places in code to instrument).

[iliakan]

So when ASYNCIFY comes across an indirect call... Does it instrument all the functions with the matching signature? Or just all the functions? ;)

[kripken]

I think right now it assumes any indirect call can go anywhere, which could be improved to just the functions who have a reference taken, and of the right signature,

binaryen/src/passes/Asyncify.cpp

Lines 616 to 625 in cd90ef4

	void visitCallIndirect(CallIndirect* curr) {
	if (curr->isReturn) {
	Fatal() << "tail calls not yet supported in asyncify";
	}
	if (canIndirectChangeState) {
	info.canChangeState = true;
	}
	// TODO optimize the other case, at least by type
	}
	};

JSPI will avoid all this overhead, however.

[iliakan]

I have only one async function launch_editor_js.

I tried to use -sASYNCIFY_IGNORE_INDIRECT, and again there are many instrumented functions.

Here's the top of the advise list:

[asyncify] launch_editor_js is an import that can change the state
[asyncify] __wasi_fd_sync is an import that can change the state
...

My function is at the top, but then goes __wasi_fd_sync and takes almost all app with it.

Why is __wasi_fd_sync is instrumented?

It's in the DEFAULT_ASYNCIFY_IMPORTS list:

https://github.com/emscripten-core/emscripten/blob/main/emcc.py#L102-L110

Is it possible (and will it be ok) to exclude __wasi_fd_sync?

[kripken]

Ok, in that case then emscripten does need a fix to allow removing things from the default list.

[iliakan]

Will it be ok to remove it from the list in emcc.py, while keeping #ifdef ASYNCIFY in library_wasi.js ?

[kripken]

No, I think it needs to stay in emcc.py as it's the right default. library_wasi just defines the code, but doesn't annotate it as an asyncify import.

But we can allow the removelist to override the defaults in emcc.py. A PR with that would make sense I think.

[iliakan]

I tried to remove the __wasi_fd_sync item by editing emcc.py, just to see how it goes, and got this Fatal message (above).

Where does it come from? Guess there's something else to change?

[kripken]

Hmm, perhaps the remove-list cannot contain an import name in general.

We could change that so the remove-list is used in two ways: First, if it is the name of an import, then the import is removed from the list of imports. Second, if it is not the name of an import, then it is passed to the list of things to remove in the Asyncify pass. That is, we don't need to inform the Asyncify pass about removing imports - we can remove that in emcc.py