New Asyncify

[rhysd]

trafficstars

This branch is an experiment to use new Asyncify for vim.wasm's event loop.

Implementation Status

• [x] Replace SharedArrayBuffer and Atomics with simple postMessage
• [x] Use Asyncify.handleSleep to wait for messages from main thread in blocking form in C
• [x] Remove browser compatibility check since SharedArrayBuffer and Atomics are no longer used
• [ ] Tweak build configuration
  • [x] Stack size: 20480 seems enough
• [ ] Check browser compatibility
  • [x] Chrome
  • [x] Firefox
  • [ ] Safari

Current Issues

• Does not work on Safari 12.1.2
  • https://twitter.com/Linda_pp/status/1158771574792527872
• Vim utilizes indirect function calls for running editor commands so SYNCIFY_IGNORE_INDIRECT does not work. Blacklisting may work but the asynchronous functions are called in deep part of call stack so list would be big and hard to maintain
• Performance seems degraded. Especially CPU usage at initialization is quite high

Resources

• https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html
• https://emscripten.org/docs/porting/asyncify.html

[rhysd]

Regarding to Safari issue, warning that running dependencies is taking time is output repeatedly at several seconds interval on starting Vim. Safari continues to allocate memory and finally macOS crashes when it runs out of memory.

[kripken]

Nice work :)

About Safari, I think a build of this is enough for a bug report for WebKit. It sounds like their JIT is hitting a problem, probably due to the extra overhead of asyncify (the many more locals, which can lead to worse than linear time and memory).

May be worth trying the asyncify whitelist/blacklist feature, btw, it may help with performance.

[rhysd]

@kripken

Thanks for the comment.

About Safari, I think a build of this is enough for a bug report for WebKit. It sounds like their JIT is hitting a problem, probably due to the extra overhead of asyncify (the many more locals, which can lead to worse than linear time and memory).

Yeah, I agree that it would be bug of WebKit. In order to clarify it is a bug of WebKit, not Safari, I tried WebKit nightly build r248339. I confirmed it consumed 2GB memory and it finally caused Maximum call stack size exceeded error.

May be worth trying the asyncify whitelist/blacklist feature, btw, it may help with performance.

Yes, I should try :) My understanding is that when calling function which may unwind stack, all functions on call stack should be instrumented. Since a function to wait for user's input with blocking is called at the bottom of a bit deep call stack, the list would be big. Since vim.wasm must follow the upstream changes, I need to investigate if the list is maintenable.

[ashwinkjoseph]

hey, is this PR still active? is anyone working on it or do you need a hand in finishing this? I would like to use this project for an educational website and I would like it to have support for firefox and safari as well. So if possible, I can help you out with this PR

[rhysd]

Actually not active. This PR is for experiment and not meant to be merged eventually. The second point of 'Current Issues' in description is hard in terms of maintenance.

[ashwinkjoseph]

Actually not active. This PR is for experiment and not meant to be merged eventually. The second point of 'Current Issues' in description is hard in terms of maintenance.

Okay, thanks for letting me know. Let me know if I can help you with this project in any way.