1 2 The build system (at least autotools-based one) should detect and configure
3 emscripten correctly.
4 5 Due to the limitations of webassembly, finding all roots on the stack needs
6 more coordination with the code using the collector than on other platforms.
7 There are two strategies for dealing with this:
8 9 1. Compile any code relying on the collector with
10 -sBINARYEN_EXTRA_PASSES='--spill-pointers' option. This instructs the
11 C compiler to always keep roots in a place where the collector can find
12 them. This is the simplest option but there is some negative impact on
13 the code size and performance.
14 15 2. Only trigger the GC at points where it can be guaranteed that there are
16 no pointers on the stack. When running in the browser, this can be done,
17 e.g., in the main event loop using emscripten_set_timeout(). Triggering
18 the collection manually involves calling GC_enable(), GC_gcollect() and
19 GC_disable() in succession, having also a GC_disable() call at start.
20 This method does not have a drawback on the code size and performance but
21 might lead to the garbage collection running too often or, vice versa,
22 rarely if the timeouts are chosen incorrectly, as a consequence, leading
23 to the heap growth.
24 25 As of now, gctest almost passes, except for the tests that involve a_get().
26 27 No thread support for now. No idea how to stop other threads (perhaps we need
28 support from JS side).
29 30 How to build (LDFLAGS could be omitted depending on the strategy):
31 32 # source EMSDK first
33 LDFLAGS="-sBINARYEN_EXTRA_PASSES='--spill-pointers'" emconfigure ./configure
34 emmake make gctest.html
35 # point your browser at .libs/gctest.html or call `node .libs/gctest.js`
36