1264635 - jit-test recover-object-bug1175233.js fails with "assertRecoveredOnBailout failed" with zealous GC

Status: NEW

(Core :: JavaScript: GC, defect)

Description

[Jon Coppeard (:jonco)]

Since compacting of script arenas landed in bug 1259180, the following test fails:

$ JS_GC_ZEAL=14,200 ./jit-test/jit_test.py --args="--ion-eager --ion-offthread-compile=off" default-build/shell recover-object-bug1175233.js 
[1|0|0|0]  50% ==========================>                            |   3.8s
Assertion failure: input()->isRecoveredOnBailout() == mustBeRecovered_ (assertRecoveredOnBailout failed during compilation), at /Users/jon/work/compacting/js/src/jit/Recover.cpp:1510
Exit code: -11
FAIL - ion/recover-object-bug1175233.js
[1|1|0|0] 100% ======================================================>|   3.9s
FAILURES:
    --ion-pgo=on /Users/jon/work/compacting/js/src/jit-test/tests/ion/recover-object-bug1175233.js
TIMEOUTS:


Note the zeal frequency of 200 is required to reproduce this.

Comment 1

[Jon Coppeard (:jonco)]

This happens even without compacting GC, for example:

JS_GC_ZEAL=2,10 ./jit-test/jit_test.py --args="--ion-eager --ion-offthread-compile=off" default-build/shell recover-object-bug1175233.js

I'm not sure if this is a real problem or not but needinfo'ing nbp just in case.

Comment 2

[Nicolas B. Pierron [:nbp]]

jit-test/tests/ion/recover-object-bug1175233.js uses --ion-pgo=on, which enables the code coverage feature.  This code coverage feature is implemented using the ScriptCounts structure, which is allocated the first time we execute a script.

If the allocation of ScriptCount fails (initScriptCount [1]), this should not change the way the script runs, and we continue without any code coverage instrumentation.  This test case assume that all code coverage allocation succeeded and asserts that we can optimize the code based on the code coverage counters, by removing unused branches.

Previously initScriptCount did not cause any OOM reports on failure, so the code is still well armored against null pointers flowing as results of maybeGetPCCounts [2].  What might happen is that we either query the ScriptCountsMap with the wrong JSScript, or we failed to re-key one of the entry of the ScriptCountMaps.

Looking at the patch from Bug 1259180, I suggest you look around JSCompartment::fixupScriptMapsAfterMovingGC() function.  At first sight I have no clue from where this might come from.

[1] https://dxr.mozilla.org/mozilla-central/search?q=%2Bfunction-ref%3A%22JSScript%3A%3AinitScriptCounts%28struct+JSContext+*%29%22
[2] https://dxr.mozilla.org/mozilla-central/search?q=%2Bfunction-ref%3A%22JSScript%3A%3AmaybeGetPCCounts%28jsbytecode+*%29%22