Created attachment 323330 [details] Patch

Comment on attachment 323330 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=323330&action=review > Source/bmalloc/ChangeLog:11 > + (bmalloc::api::tryLargeMemalignVirtual): Call Heap::tryAllocateLarge(), > + which won't intentionally crash if the allocation fails. Why is this important? I see that it is correct, because it's called in tryLargeMemalignVirtual, but seems odd to change cross-platform behavior in an ARM64 commit.

Comment on attachment 323330 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=323330&action=review >> Source/bmalloc/ChangeLog:11 >> + which won't intentionally crash if the allocation fails. > > Why is this important? I see that it is correct, because it's called in tryLargeMemalignVirtual, but seems odd to change cross-platform behavior in an ARM64 commit. I don't mind doing it in a separate patch. But it avoids ~500 WASM crashes that occur because WASM::Memory tries to allocate 4GB of virtual memory while the current ARM64 Gigacage implementation doesn't support such large allocations.

I would just mention that in the changelog, then.

(In reply to Zan Dobersek from comment #3) > Comment on attachment 323330 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=323330&action=review > > >> Source/bmalloc/ChangeLog:11 > >> + which won't intentionally crash if the allocation fails. > > > > Why is this important? I see that it is correct, because it's called in tryLargeMemalignVirtual, but seems odd to change cross-platform behavior in an ARM64 commit. > > I don't mind doing it in a separate patch. But it avoids ~500 WASM crashes > that occur because WASM::Memory tries to allocate 4GB of virtual memory > while the current ARM64 Gigacage implementation doesn't support such large > allocations. That sounds like a bug?

Comment on attachment 323330 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=323330&action=review >>>> Source/bmalloc/ChangeLog:11 >>>> + which won't intentionally crash if the allocation fails. >>> >>> Why is this important? I see that it is correct, because it's called in tryLargeMemalignVirtual, but seems odd to change cross-platform behavior in an ARM64 commit. >> >> I don't mind doing it in a separate patch. But it avoids ~500 WASM crashes that occur because WASM::Memory tries to allocate 4GB of virtual memory while the current ARM64 Gigacage implementation doesn't support such large allocations. > > That sounds like a bug? Yeah, that sounds like a bug. It is not intended behavier, right? I think that the correct fix is fixing bmalloc side. BTW, is this specific to ARM64 Gugacage? Or can we reproduce this in x64? I think it is ARM64 specific since we do not see such crashes in x64 test bot.

(In reply to Yusuke Suzuki from comment #6) > I think it is ARM64 specific since we do not see such crashes in x64 test > bot. The GTK and WPE bots are not running the JSC tests marked as memory-limited since bug 175140

(In reply to Carlos Alberto Lopez Perez from comment #7) > (In reply to Yusuke Suzuki from comment #6) > > I think it is ARM64 specific since we do not see such crashes in x64 test > > bot. > > The GTK and WPE bots are not running the JSC tests marked as memory-limited > since bug 175140 Oh, I've just run trunk JSCOnly on Linux x64 with `run-jsc-stress-tests -j path/to/jsc JSTests/wasm.yaml` and all the tests (1010 tests) pass.

Comment on attachment 323330 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=323330&action=review > Source/bmalloc/bmalloc/bmalloc.h:74 > - return heap.allocateLarge(lock, alignment, size, AllocationKind::Virtual); > + return heap.tryAllocateLarge(lock, alignment, size, AllocationKind::Virtual); I don't know much about bmalloc, but this function is named tryLargeMemalignVirtual, so it looks to be clearly broken currently.

Comment on attachment 323330 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=323330&action=review >>>>> Source/bmalloc/ChangeLog:11 >>>>> + which won't intentionally crash if the allocation fails. >>>> >>>> Why is this important? I see that it is correct, because it's called in tryLargeMemalignVirtual, but seems odd to change cross-platform behavior in an ARM64 commit. >>> >>> I don't mind doing it in a separate patch. But it avoids ~500 WASM crashes that occur because WASM::Memory tries to allocate 4GB of virtual memory while the current ARM64 Gigacage implementation doesn't support such large allocations. >> >> That sounds like a bug? > > Yeah, that sounds like a bug. It is not intended behavier, right? > I think that the correct fix is fixing bmalloc side. > BTW, is this specific to ARM64 Gugacage? Or can we reproduce this in x64? > I think it is ARM64 specific since we do not see such crashes in x64 test bot. In ensureGigacage(), the sizes for different kinds are summed up and that value is then used to do a single allocation. On x86_64 this sum exceeds 80GB, while on ARM64 it's for now limited to around 3GB (not counting alignment adjustments). Bug #177605 will increase those values. Crash occurs under MemoryManager::tryAllocateVirtualPages(), in WasmMemory implementation file. The Memory::fastMappedBytes() value is used as the size of allocation, which translates to 4GB. The Gigacage on x86_64 has no problems to accommodate that, while on ARM64 the allocation fails and produces a crash because of Heap::allocateLarge() being used in bmalloc::tryLargeMemalignVirtual().

bmalloc part spun off into bug #178654.

Created attachment 324546 [details] Patch

Comment on attachment 324546 [details] Patch Clearing flags on attachment: 324546 Committed r224171: <https://trac.webkit.org/changeset/224171>

All reviewed patches have been landed. Closing bug.

BTW, right now, shouldBeEnabled inside Gigacage.cpp returns false for ARM64. You may want to enable that for Linux or change the guard to return false if IOS.

Reopening in light of that.

Zan, do you want to look at this?

It's been enabled back for ARM64 in r225701. https://trac.webkit.org/changeset/225701/webkit

<rdar://problem/38765155>