After https://trac.webkit.org/r249578, the test `stress/test-out-of-memory.js` was introduced to test some paths that are taken during memory allocation, mainly the path where `allocationLarge` fails due to unavailable space for large allocations (m_largeFree). However, this test has some assumptions that are not valid into ARMv7 and MIPS ports. The current behavior of the test in those architectures is that it does not throw during `new ArrayBuffer(1000)` allocation site, because eden collection keeps happening between iterations. The collection is trigged into those architectures because the amount of stress `new Promise` generates into GC limits is not enough to avoid collection while loop is executing. Changing the size of `UInt8Array` from `80000000` to `160000000` enables us to finally avoid collection happening during `ArrayBuffer` allocation loop, but we can't guarantee this test is always going to execute without error when Gigacage is disabled, given we can reach an OOM state in some allocations that need to succeed, turning this test flawky for those architectures. Given that, I think we should skip this test for ARMv7 and MIPS.
Created attachment 379170 [details] Patch
Comment on attachment 379170 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=379170&action=review > JSTests/ChangeLog:12 > + is trigged into those architectures because the amount of stress /trigged into/triggered on/ > JSTests/ChangeLog:20 > + some allocations that need to succeed, turning this test flawky for those /turning this test flawky/making this test flaky/
Created attachment 379319 [details] Patch
Thank you very much for the review!
Comment on attachment 379319 [details] Patch Clearing flags on attachment: 379319 Committed r250185: <https://trac.webkit.org/changeset/250185>
All reviewed patches have been landed. Closing bug.
<rdar://problem/55591617>