http://trac.webkit.org/changeset/197226 removed the on demand executable allocator which was used by 32 bit ARM Linux platforms. Since r197226, only fixed allocator is available, which means only 16Mb RAM is available on 32 bit ARM devices. Failing tests: mozilla-tests.yaml/js1_5/Regress/regress-159334.js.mozilla-baseline jsc-layout-tests.yaml/js/script-tests/regress-141098.js.layout-no-llint jsc-layout-tests.yaml/js/script-tests/dfg-float32array.js.layout-no-llint jsc-layout-tests.yaml/js/script-tests/dfg-float64array.js.layout-no-llint jsc-layout-tests.yaml/js/script-tests/dfg-int16array.js.layout-no-llint jsc-layout-tests.yaml/js/script-tests/dfg-int32array-overflow-values.js.layout-no-llint jsc-layout-tests.yaml/js/script-tests/dfg-int32array.js.layout-no-llint jsc-layout-tests.yaml/js/script-tests/dfg-int8array.js.layout-no-llint jsc-layout-tests.yaml/js/script-tests/dfg-osr-entry-hoisted-clobbered-structure-check.js.layout-no-llint jsc-layout-tests.yaml/js/script-tests/dfg-uint16array.js.layout-no-llint jsc-layout-tests.yaml/js/script-tests/dfg-uint32array-overflow-values.js.layout-no-llint jsc-layout-tests.yaml/js/script-tests/dfg-uint32array.js.layout-no-llint jsc-layout-tests.yaml/js/script-tests/dfg-uint8array.js.layout-no-llint jsc-layout-tests.yaml/js/script-tests/dfg-uint8clampedarray.js.layout-no-llint
Apple already skipped these tests in http://trac.webkit.org/changeset/196625 and I unskipped them on Linux in http://trac.webkit.org/changeset/196762 . But after http://trac.webkit.org/changeset/197226 these tests started to fail. Is there a reason to remove the on demand executable allocator? There weren't any explanation in the original bug report.
I tried to increase the memory size to 32Mb (JSC_jitMemoryReservationSize=33554432), which fixed these tests, but made 150 other tests fail.
Increasing jitMemoryReservationSize to 32Mb fixes the OOM issue with the ARMAssembler (ARM instruction set) and we don't get new crashes. But with ARMv7Assembler (Thumb2 instruction set) we get ~150 crashes if we increase the JIT memory above 16Mb (maximum jump with 24 bit address!) Zoltán fixed a similar bug in ARMv7Assembler 3 years ago: http://trac.webkit.org/changeset/146396
Are these just timing out? (In reply to comment #0) > http://trac.webkit.org/changeset/197226 removed the on demand executable > allocator > which was used by 32 bit ARM Linux platforms. Since r197226, only fixed > allocator > is available, which means only 16Mb RAM is available on 32 bit ARM devices. > > Failing tests: > mozilla-tests.yaml/js1_5/Regress/regress-159334.js.mozilla-baseline > jsc-layout-tests.yaml/js/script-tests/regress-141098.js.layout-no-llint > jsc-layout-tests.yaml/js/script-tests/dfg-float32array.js.layout-no-llint > jsc-layout-tests.yaml/js/script-tests/dfg-float64array.js.layout-no-llint > jsc-layout-tests.yaml/js/script-tests/dfg-int16array.js.layout-no-llint > jsc-layout-tests.yaml/js/script-tests/dfg-int32array-overflow-values.js. > layout-no-llint > jsc-layout-tests.yaml/js/script-tests/dfg-int32array.js.layout-no-llint > jsc-layout-tests.yaml/js/script-tests/dfg-int8array.js.layout-no-llint > jsc-layout-tests.yaml/js/script-tests/dfg-osr-entry-hoisted-clobbered- > structure-check.js.layout-no-llint > jsc-layout-tests.yaml/js/script-tests/dfg-uint16array.js.layout-no-llint > jsc-layout-tests.yaml/js/script-tests/dfg-uint32array-overflow-values.js. > layout-no-llint > jsc-layout-tests.yaml/js/script-tests/dfg-uint32array.js.layout-no-llint > jsc-layout-tests.yaml/js/script-tests/dfg-uint8array.js.layout-no-llint > jsc-layout-tests.yaml/js/script-tests/dfg-uint8clampedarray.js.layout-no- > llint
(In reply to comment #4) > Are these just timing out? No, out of memory because of fixed 16Mb sized VM pool. I already added my detailed investigation: (In reply to comment #3) > Increasing jitMemoryReservationSize to 32Mb fixes the OOM issue with > the ARMAssembler (ARM instruction set) and we don't get new crashes. > > But with ARMv7Assembler (Thumb2 instruction set) we get ~150 crashes if > we increase the JIT memory above 16Mb (maximum jump with 24 bit address!) > > Zoltán fixed a similar bug in ARMv7Assembler 3 years ago: > http://trac.webkit.org/changeset/146396 It's easy to fix this bug with ARMAssembler with increasing jitMemoryReservationSize. But it would cause more problems with ARMv7Assembler.
Why is the ARM backend not falling back to the interpreter when it's out of executable memory?
(In reply to comment #6) > Why is the ARM backend not falling back to the interpreter when it's out of > executable memory? These tests explicitly disable LLINT, I don't think if it is possible to fallback in this case.
Fixing by rollout. *** This bug has been marked as a duplicate of bug 154910 ***