Skip to content

Commit

Permalink
Describe strategies to scan data roots on stack (Emscripten)
Browse files Browse the repository at this point in the history
PR #651 (bdwgc).

Update README.emscripten adding a note about the strategies that could
be employed in order for the collector to work correctly.

* docs/platforms/README.emscripten: Add info about strategies to deal
with Emscripten limitation of scanning data roots on stack; update
how-to-build instruction.
  • Loading branch information
spaghettisalat authored and ivmai committed Aug 6, 2024
1 parent 7f1503d commit d8e60d5
Showing 1 changed file with 24 additions and 4 deletions.
28 changes: 24 additions & 4 deletions docs/platforms/README.emscripten
Original file line number Diff line number Diff line change
@@ -1,15 +1,35 @@

The build system (at least autotools-based) should detect and configure
The build system (at least autotools-based one) should detect and configure
emscripten correctly.

Due to the limitations of webassembly, finding all roots on the stack needs
more coordination with the code using the collector than on other platforms.
There are two strategies for dealing with this:

1. Compile any code relying on the collector with
-sBINARYEN_EXTRA_PASSES='--spill-pointers' option. This instructs the
C compiler to always keep roots in a place where the collector can find
them. This is the simplest option but there is some negative impact on
the code size and performance.

2. Only trigger the GC at points where it can be guaranteed that there are
no pointers on the stack. When running in the browser, this can be done,
e.g., in the main event loop using emscripten_set_timeout(). Triggering
the collection manually involves calling GC_enable(), GC_gcollect() and
GC_disable() in succession, having also a GC_disable() call at start.
This method does not have a drawback on the code size and performance but
might lead to the garbage collection running too often or, vice versa,
rarely if the timeouts are chosen incorrectly, as a consequence, leading
to the heap growth.

As of now, gctest almost passes, except for the tests that involve a_get().

No thread support for now. No idea how to stop other threads (perhaps we need
support from JS side).

How to build:
How to build (LDFLAGS could be omitted depending on the strategy):

# source EMSDK first
emconfigure ./configure
LDFLAGS="-sBINARYEN_EXTRA_PASSES='--spill-pointers'" emconfigure ./configure
emmake make gctest.html
# point your browser at .libs/gctest.html
# point your browser at .libs/gctest.html or call `node .libs/gctest.js`

0 comments on commit d8e60d5

Please sign in to comment.