Skip to content

CompileError: WebAssembly.instantiate(): size 8279546 > maximum function size 7654321 #16690

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
donalffons opened this issue Apr 9, 2022 · 5 comments

Comments

@donalffons
Copy link

I'm encountering the error

failed to asynchronously prepare wasm: CompileError: WebAssembly.instantiate(): size 8279546 > maximum function size 7654321 @+5057364

at WASM startup when setting -sDISABLE_EXCEPTION_CATCHING=0 and -O3 in my project. Is there anything I can do about this error?

@donalffons
Copy link
Author

What seems to resolve this for me is to enable -flto during compile and link.

@kripken
Copy link
Member

kripken commented Apr 11, 2022

I guess lto might manage to reduce that function below the maximum size browsers allow.

In general, you can disable inlining on functions that end up huge like this, or build that file with -Os etc. Or if the function is machine-generated, not generate a single big function but split it up, etc.

@donalffons
Copy link
Author

Thanks for your reply. I did use -Os during compilation already (but used -O3 during link) and still encountered the issue. It would be great if Emscripten would handle splitting up large function automatically or give a warning at compile/link time along with more information on which function causes this problem. Not sure if that would be possible / feasible though...

@kripken
Copy link
Member

kripken commented Apr 12, 2022

There have been some thoughts about function splitting and outlining, although for other purposes, but it could help here too. I think it's definitely feasible, if someone has the time, but it may not be easy (when splitting you need to pass around all relevant locals, and in such a huge function I worry you'd hit browser limits on the # of parameters/returns. Spilling to memory might help, but that could be extremely slow).

@donalffons
Copy link
Author

Great to hear that you have this on the radar already / still. Since this is not urgent for me any more, I will close this issue.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants