1739576 - Wasm heaps should be able to grow to maxBufferByteLength, not maxBufferByteLength - 64K

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, defect, P3)

Description

[Lars T Hansen [:lth]]

For Memory64 on 64-bit systems there is some confusion about what the max heap length is. maxBufferByteLength() should be authoritative: its value should signify the max that a wasm heap can be grow to, from the user program's perspective. Currently however we use this value directly to compute the max mappable pages, and this reduces the heap limit by one page. The problem is likely in MaxMemoryPages, which uses maxBufferByteLength() directly and does not incorporate eg the value from ComputeMappedSize, for this particular configuration.

Frankly, with the number of combinations of features (almost-2GB heaps on 32-bit systems, almost-2GB heaps on 64-bit systems (MIPS64), almost-4GB heaps on 64-bit systems (Cranelift), 4GB heaps on 64-bit systems (m32 for baseline/ion), and beyond-4GB heaps on 64-bit systems (m64 for baseline/ion), together with both compile-time and run-time options for the large-memory trick for m32 on 64-bit systems) it's no wonder this code is a little shaky.

Comment 1

[Lars T Hansen [:lth]]

Attachment: Bug 1739576 - Make 8GB available. r?rhunt

Tidy up MaxMemoryPages(IndexType::I64) so that it returns a value
corresponding to the max buffer byte length. Fix two asserts that
were incorrect and that triggered when making this change.

Add a test that the max memory pages for i64 is indeed at least 8GB.

Drive-by fix to allow a test to OOM without reporting that as a
failure.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f369c2fc3ab7
Make 8GB available. r=rhunt

Comment 3

[Cristina Cozmuta (:CrissCozmuta)]

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