Working (but slow) support for pthreads + memory growth #8365

kripken · 2019-03-28T22:18:19Z

(in wasm - no support in asm.js)

Add GROWABLE_HEAP_* methods that replace each load and store in JS. These safely check if memory grew, and updates the buffer and views if so. The JS optimizer is used to instrument the JS in this way, so it works for user JS as well.
Show a warning about the slowness during compilation.
Proxy emscripten_resize_heap to the main thread, and handle races where a thread asks for growth but another thread grows it to a lower or higher value meanwhile - loop until successful, or an error is hit.
Make sbrk threadsafe using that.
Rewrite brk using sbrk, to avoid writing two pieces of threadsafe code.

Blocked on https://bugs.chromium.org/p/v8/issues/detail?id=9062 , so this is not fully tested yet - it doesn't test an actual memory growth, but it does test that instrumenting the code works.

…ere is a source of nondeterminism in the JS backend

kripken · 2019-03-28T23:18:12Z

Ah, I see some errors on CI that I missed in the subset of tests I ran locally. I don't see a way to turn this into a draft PR - is there? Anyhow, this is still a wip.

dschuff · 2019-03-28T22:59:13Z

tests/pthread/test_pthread_memory_growth.c

+  pthread_t thr;
+
+  printf("start\n");
+  EM_ASM({ assert(HEAP8.length === 32 * 1024 * 1024, "start at 32MB") });


Hmm, it's just test code, and convenient to do it all on a single line? Maybe I don't see the benefit to using EM_JS here?

There's no benefit, other than everything should use EM_JS unless there's a good reason not to?

In general yeah, but it's just not inline, so it's more typing and less immediately obvious to the reader - the only advantages of EM_ASM, basically. I agree EM_JS is the preferred thing for most normal code though.

kripken · 2019-03-30T21:40:26Z

Ok, I pushed a fix for modularize here. I ran into some MODULARIZE_INSTANCE pre-existing bugs, which I opened #8372 for, and which should land before this.

Thanks for testing @Brion! Which HEAP* accessors did you need to change? Any emscripten code or code that is optimized with it (pre-js etc.) should be ok. The only risk is completely external JS, is that the case you are seeing?

In general it's safest to use those special GROWABLE_HEAP_* accessors - we may want to make them exportable, and could make them also work in asm.js mode. Otherwise, anywhere you receive a pointer to memory from somewhere else is a place you must check if memory was grown, as it could be a pointer into higher memory than existed before. So around any such pointer arrival you could, if in wasm + pthreads + growth, check and recreate the buffer views. We could perhaps create a function for that, updateHeapViews perhaps, that is a no-op in all modes but wasm + pthreads + growth (but you'd be responsible for placing it in the right places).

bvibber · 2019-03-30T22:06:48Z

Yeah these are in my custom JS library mix-ins, where I either malloc a buffer and write into it or create a typed array view for a C-created buffer to take data out. I'm not doing a lot of individual loads/stores; mostly data's coming as arguments on a callback, some of which are pointers/length pairs for buffers to export, which may be beyond the end of the old buffer views.

I think it should work to run updateGlobalBufferViews() manually before making a subview directly from HEAPU8, HEAPF32 etc, but I think that's going to be error-prone as forgetting will sometimes work, sometimes not.

It might feel more natural to have view-creation accessors that wrap that check-and-update call, like:

GROWABLE_HEAP_VIEW_U32(start, end)

kripken · 2019-04-01T22:31:41Z

Yeah, view creators are a natural fit too, added now.

Also added docs about this.

bvibber · 2019-04-02T00:03:00Z

The view accessors look perfect, thanks!

dschuff · 2019-04-05T20:39:17Z

src/preamble.js

-#endif
+
+#if MODULARIZE
+// In modularize mode the wasmMemory and others are received in an onmessage, and that


should this be "in pthreads mode" rather than "modularize mode"

Fixing comment.

dschuff · 2019-04-05T20:40:13Z

tests/pthread/test_pthread_memory_growth.c

+  pthread_t thr;
+
+  printf("start\n");
+  EM_ASM({ assert(HEAP8.length === 32 * 1024 * 1024, "start at 32MB") });


There's no benefit, other than everything should use EM_JS unless there's a good reason not to?

dschuff · 2019-04-05T20:43:29Z

tests/test_browser.py

+  def test_pthread_growth_mainthread(self):
+    def run(emcc_args=[]):
+      # Note that this test may not pass on Chrome until 75, due to https://bugs.chromium.org/p/v8/issues/detail?id=9062
+      self.btest(path_from_root('tests', 'pthread', 'test_pthread_memory_growth_mainthread.c'), expected='1', args=['-s', 'USE_PTHREADS=1', '-s', 'PTHREAD_POOL_SIZE=2', '-s', 'ALLOW_MEMORY_GROWTH=1', '-s', 'TOTAL_MEMORY=32MB', '-s', 'WASM_MEM_MAX=256MB'] + emcc_args, also_asmjs=False)


should test in PROXY_TO_PTHREAD mode too?

that won't work yet because of chromium issue 9065, same as test_pthread_growth. I'll add a PROXY_TO_PTHREAD mode in that test.

dschuff · 2019-04-05T20:44:27Z

tools/js-optimizer.js

@@ -5887,6 +5887,73 @@ function safeHeap(ast) {
  });
 }

+function growableHeap(ast) {


should this have some comment like "transform HEAP8 etc heap accesses to calls to GROWABLE_HEAP_LOAD_I8" or something?

Adding a comment.

…main thread can work (and hopefully soon unstable will make the thread version work too)

…ts for now

kripken · 2019-04-05T23:54:20Z

I tried to use chrome unstable so that at least part of the new tests here could pass, but it fails on unrelated things on circle, so that'll need to be looked at separately. As a result, for now the new tests are disabled.

…ore#8365) (in wasm - no support in asm.js) Background: WebAssembly/design#1271 * Add GROWABLE_HEAP_* methods that replace each load and store in JS. These safely check if memory grew, and updates the buffer and views if so. The JS optimizer is used to instrument the JS in this way, so it works for user JS as well. * Show a warning about the slowness during compilation. * Make sbrk etc. threadsafe. * Rewrite brk using sbrk, to avoid writing two pieces of threadsafe code.

…ripten-core#8365)" This reverts commit a8164ac.

…ore#8365) (in wasm - no support in asm.js) Background: WebAssembly/design#1271 * Add GROWABLE_HEAP_* methods that replace each load and store in JS. These safely check if memory grew, and updates the buffer and views if so. The JS optimizer is used to instrument the JS in this way, so it works for user JS as well. * Show a warning about the slowness during compilation. * Make sbrk etc. threadsafe. * Rewrite brk using sbrk, to avoid writing two pieces of threadsafe code.

dschuff and others added 20 commits November 2, 2018 08:51

Don't allow memory growth with pthreads

0dec1b7

support pthreads+memory growth, and remove unneeded Module.buffer

1f94ede

wip

63afb6c

wip [ci skip]

6ca27b6

integration [ci skip]

1266102

working for now

caac67c

Merge branch 'pthreads_growth' into growableHeap

1e354b8

Merge remote-tracking branch 'origin/incoming' into growableHeap

b2bcf10

Merge remote-tracking branch 'origin/pthreads-growth' into growableHeap

a12ab96

fix [ci skip]

598f978

brk

e0b2261

fixe [ci skip]

812eace

temp fix

abaf515

fix [ci skip]

36373b3

fix

6a93a95

other.test_minimal_runtime_code_size: apply slop to code sizes, as th…

c883b5b

…ere is a source of nondeterminism in the JS backend

Merge branch 'slop' into growableHeap

196bd55

cleanup

e9dba56

fixes

2d2c33d

test

8220dbe

kripken requested a review from dschuff March 28, 2019 22:18

kripken added 3 commits March 28, 2019 15:44

test works

2208693

fix return values and buffer setting for asm.js from realloc_buffer

68c384d

fix

bcea7d0

kripken removed the request for review from dschuff March 28, 2019 23:18

dschuff reviewed Mar 28, 2019

View reviewed changes

kripken added 3 commits March 28, 2019 17:06

optimize sbrk - do not call get_heap_size unnecessarily [ci skip]

5b82e0a

fix

defda2d

don't test on an actual worker yet

14488b1

kripken added 3 commits April 1, 2019 15:27

add views

55c231c

docs about this stuff

db6943b

Merge remote-tracking branch 'origin/incoming' into growableHeap

c1ab19c

Merge remote-tracking branch 'origin/incoming' into growableHeap

f06f92f

kripken requested review from sbc100 and jgravelle-google April 3, 2019 17:38

dschuff reviewed Apr 5, 2019

View reviewed changes

kripken added 5 commits April 5, 2019 14:08

Merge remote-tracking branch 'origin/incoming' into growableHeap

1579291

comment

b28aff5

prepare for more testing

ccdbab0

try to use chrome unstable so growable memory + pthreads test on the …

c56168b

…main thread can work (and hopefully soon unstable will make the thread version work too)

chrome unstable fails on circle, so give up on that - and disable tes…

fb917e4

…ts for now

dschuff approved these changes Apr 8, 2019

View reviewed changes

kripken merged commit e172838 into incoming Apr 8, 2019

kripken deleted the growableHeap branch April 8, 2019 21:43

TannerRogalsky mentioned this pull request Apr 9, 2019

Merge 0.11 into master TannerRogalsky/love.js#64

Open

kripken mentioned this pull request May 9, 2019

Wasm memory cannot be grown in pthreads builds #7382

Closed

hostilefork mentioned this pull request May 9, 2019

Available memory size is fixed (enlarge it? grow dynamically?) hostilefork/replpad-js#32

Open

VirtualTim added a commit to VirtualTim/emscripten that referenced this pull request May 23, 2019

Revert "Working (but slow) support for pthreads + memory growth (emsc…

5ee6371

…ripten-core#8365)" This reverts commit a8164ac.

VirtualTim added a commit to VirtualTim/emscripten that referenced this pull request May 23, 2019

Revert "Working (but slow) support for pthreads + memory growth (emsc…

e41dfd8

…ripten-core#8365)" This reverts commit a8164ac.

kripken mentioned this pull request Aug 28, 2019

Memory growth and JS WebAssembly/WASI#82

Closed

DzmitryFil mentioned this pull request Jul 4, 2020

Wasm Threads + Memory Growth rustwasm/wasm-bindgen#2222

Closed

pavelsavara mentioned this pull request May 23, 2023

[browser][MT] Memory growth on worker could cause failure dotnet/runtime#86642

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Working (but slow) support for pthreads + memory growth #8365

Working (but slow) support for pthreads + memory growth #8365

kripken commented Mar 28, 2019 •

edited

Loading

kripken commented Mar 28, 2019

dschuff Mar 28, 2019

kripken Mar 29, 2019

dschuff Apr 5, 2019

kripken Apr 5, 2019

kripken commented Mar 30, 2019

bvibber commented Mar 30, 2019

kripken commented Apr 1, 2019

bvibber commented Apr 2, 2019

dschuff Apr 5, 2019

kripken Apr 5, 2019

dschuff Apr 5, 2019

dschuff Apr 5, 2019

kripken Apr 5, 2019

dschuff Apr 5, 2019

kripken Apr 5, 2019

kripken commented Apr 5, 2019

Working (but slow) support for pthreads + memory growth #8365

Working (but slow) support for pthreads + memory growth #8365

Conversation

kripken commented Mar 28, 2019 • edited Loading

kripken commented Mar 28, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kripken commented Mar 30, 2019

bvibber commented Mar 30, 2019

kripken commented Apr 1, 2019

bvibber commented Apr 2, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kripken commented Apr 5, 2019

kripken commented Mar 28, 2019 •

edited

Loading