923179 - GenerationalGC: jit-test asm.js/testParallelCompile.js fails in threadsafe shell builds

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jon Coppeard (:jonco) (PTO until 3rd April)]

TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | --no-baseline --no-ion --no-ti
TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | --no-baseline --no-ion
TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | 
TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | --baseline-eager
TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | --baseline-eager --no-ti --no-fpu
TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | --ion-eager
TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/asm.js/testParallelCompile.js | --ion-eager --ion-check-range-analysis
make[1]: *** [check-jit-test] Error 2

Comment 1

[Jon Coppeard (:jonco) (PTO until 3rd April)]

Actually this fails in shell builds built with --enable-threadsafe.

Comment 2

[Jon Coppeard (:jonco) (PTO until 3rd April)]

A heap post barrier is trying to access the store buffer during off-thread compilation, and this is causing an assertion (CurrentThreadCanAccessRuntime() is false).

Additionally, the ASM JS fault handler is then going into an infinite loop for the same reason.

Assertion failure: CurrentThreadCanAccessRuntime(rt), at ../gc/Heap.h:964
[Switching to Thread 0x7fffee7fc700 (LWP 19937)]

Catchpoint 1 (signal SIGSEGV), js::gc::Cell::runtimeFromMainThread (this=0x7ffff45620d0) at ../gc/Heap.h:964
964	../gc/Heap.h: No such file or directory.

Breakpoint 2, AsmJSFaultHandler (signum=11, info=0x7fffee7f8730, context=0x7fffee7f8600) at /home/jon/work/rooting/js/src/jit/AsmJSSignalHandlers.cpp:972
972	    if (HandleSignal(signum, info, context))
(gdb) bt
#0  AsmJSFaultHandler (signum=11, info=0x7fffee7f8730, context=0x7fffee7f8600) at /home/jon/work/rooting/js/src/jit/AsmJSSignalHandlers.cpp:972
#1  <signal handler called>
#2  js::gc::Cell::runtimeFromMainThread (this=0x7ffff45620d0) at ../gc/Heap.h:964
#3  0x0000000000461e90 in js::EncapsulatedValue::runtimeFromMainThread (v=...) at ../gc/Barrier.h:620
#4  0x0000000000461765 in js::EncapsulatedValue::shadowRuntimeFromMainThread (v=...) at ../gc/Barrier.h:627
#5  0x000000000046172f in js::HeapValue::writeBarrierPost (value=..., addr=0x7ffff4569fe0) at ../gc/Barrier.h:715
#6  0x00000000004616f3 in js::HeapValue::post (this=0x7ffff4569fe0) at ../gc/Barrier.h:730
#7  0x000000000045d25b in js::HeapValue::operator= (this=0x7ffff4569fe0, v=...) at ../gc/Barrier.h:681
#8  0x00000000004b69b0 in JSFunction::setExtendedSlot (this=(JSFunction *) 0x7ffff4569fa0 [object Function <unnamed>], which=0, val=...) at ../jsfun.h:557
#9  0x000000000096f471 in js::NewAsmJSModuleFunction (cx=0x1bba360, origFun=(JSFunction *) 0x7ffff456b940 [object Function <unnamed>], moduleObj=(JSObject * const) 0x7ffff45620d0 [object AsmJSModuleObject])
    at /home/jon/work/rooting/js/src/jit/AsmJSLink.cpp:666
#10 0x0000000000914493 in js::CompileAsmJS (cx=0x1bba360, parser=..., stmtList=0x7fffd8000a70, validated=0x7fffee7f8ed7) at /home/jon/work/rooting/js/src/jit/AsmJS.cpp:6519
#11 0x00000000005663f0 in js::frontend::Parser<js::frontend::FullParseHandler>::asmJS (this=0x7fffee7fae98, list=0x7fffd8000a70) at /home/jon/work/rooting/js/src/frontend/Parser.cpp:2534
#12 0x0000000000578fa0 in js::frontend::Parser<js::frontend::FullParseHandler>::maybeParseDirective (this=0x7fffee7fae98, list=0x7fffd8000a70, pn=0x7fffd8000ae0, cont=0x7fffee7f8faf)
    at /home/jon/work/rooting/js/src/frontend/Parser.cpp:2610
#13 0x0000000000573a09 in js::frontend::Parser<js::frontend::FullParseHandler>::statements (this=0x7fffee7fae98) at /home/jon/work/rooting/js/src/frontend/Parser.cpp:2654

Comment 3

[Luke Wagner [:luke]]

IIUC, an off-main-thread ExclusiveContext is allowed to create and manipulate GC things in the ExclusiveContext's compartment and CompileAsmJS does this at the end.  Is that right?

Comment 4

[Jon Coppeard (:jonco) (PTO until 3rd April)]

(In reply to Luke Wagner [:luke] from comment #3)

So I don't understand all the aspects of threading in SM, but yes, according to the comments an off-main-thread ExclusiveContext can access GC things in its own compartment.  And since it's not on the main thread, it should never be able to see any nursery allocated things.

The problem here is that we're asserting we can access the main thread's runtime too soon.  It's safe for us to use the runtime to find the location of the nursery, since this is allocated once and never changes (I initially thought this got resized, but it doesn't, at least not at the moment).  And we already check we're on the right thread if it turns out we need to insert entries in the store buffer, which cannot happen if we are not on the main thread.  

So actually I think the fix is just to use runtimeFromAnyThread() rather than runtimeFromMainThread() in the appropriate places in Barrier.h.

Comment 5

[Jon Coppeard (:jonco) (PTO until 3rd April)]

Attachment: bug923179-parallelCompile

Comment 6

[Terrence Cole [:terrence]]

Comment on attachment 815421 [details] [diff] [review]
bug923179-parallelCompile

Review of attachment 815421 [details] [diff] [review]:
-----------------------------------------------------------------

Excellent! r=me

Comment 7

[Jon Coppeard (:jonco) (PTO until 3rd April)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b49e069aeddd

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b49e069aeddd