emscripten-core / emscripten-core/emscripten
Porting Boehm to Emscripten
- Dominant language
- C++
- Stars
- 27.6k
- Forks
- 3.6k
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 105
Description
I have a fork of Boehm cooking at https://github.com/ivmai/bdwgc/compare/master...juj:bdwgc:emscripten , where I am looking to make the latest Boehm upstream work with Emscripten. (it looks like its Emscripten support has regressed by quite a bit since Unity has last synced with upstream Boehm many many years ago)
My idea is to experiment with a couple of different strategies for Boehm + Emscripten support:
1. **"the way it was intended to work"**: using Binaryen's `--spill-pointers` pass that @kripken restored to work this summer, to automatically spill all pointers from wasm locals to the stack, so that Boehm will be able to scan the stack,
2. **"the way that Unity currently uses Boehm"**: i.e. enable only "asynchronous GC collection", where GC collection only occurs when no wasm code (with managed local functions) is on the stack, for example via a delayed "`setTimeout(GC_gcollect, 0);`" type of call.
3. **"cooperative garbage collection"**: this is the idea from #17131, experimenting with scenarios where user code is able to manually annotate all GC pointers via some kind of a `DECLARE_GC_POINTER(myPtr);`. While this would be brittle, it is something that might work well in automatic codegen scenarios where correctness can be verified.
Looking at current Boehm Emscripten support, someone landed a change there that switches Boehm to require -sASYNCIFY to be enabled at the same time, thinking that it would enable stack scanning. ( https://github.com/ivmai/bdwgc/commit/1431bda1a87d66d669faab00aefe34349c54a56a#diff-f82cc1b932242998b29875a64e8490b12c461ba04ab72e59ef0ac5b2efa8af4a ).
While I am not intimate with the 100% details of ASYNCIFY, I was pondering that maybe that would not be correct at all? @kripken true or false: ASYNCIFY only spills locals to the stack only in those functions that can lead to calling asyncified functions, but not in *all* of the functions? In other words, enabling ASYNCIFY is not enough to substitute the current need for a `--spill-pointers` pass? I.e. simply enabling ASYNCIFY would not properly spill pointers on the stack?
Also doesn't ASYNCIFY use its own stack that is separate from the regular stack? (would `emscripten_scan_stack()` scan this Asyncify stack?)
How would I appropriately enable the `--spill-pointers` pass in Binaryen? I've so far tried just to do
```diff
diff --git a/emcc.py b/emcc.py
index f2dc5821a..28ee19f4d 100755
--- a/emcc.py
+++ b/emcc.py
@@ -594,6 +594,8 @@ def should_run_binaryen_optimizer():
def get_binaryen_passes():
passes = []
+ if not settings.BOOTSTRAPPING_STRUCT_INFO:
+ passes += ['--spill-pointers']
optimizing = should_run_binaryen_optimizer()
# safe heap must run before post-emscripten, so post-emscripten can apply the sbrk ptr
if settings.SAFE_HEAP:
```
though that gets me correctness problems. Looks like printf() starts to fail with that, and most of the core0 tests in the suite as well. I am not sure if there might be some ordering dependencies with other passes that this spilling pointers pass should be run at? Or maybe something might be off with the `--spill-pointers` pass?
Contributor guide
Assessment
This issue has not been assessed yet.