1855732 - Make wasm-gc trailer sizes available to the tenured-heap's when-to-GC decision-making machinery

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, defect)

Description

[Ben Visness [:bvisness]]

Some elements of the Kotlin wasm benchmark suite allocate ridiculous amounts of memory (hundreds of gigabytes on my machine). V8 does not suffer the same.

For example, you can clone https://github.com/bvisness/kotlin-wasm-benchmarks and run gradle jsShell_wasmSingleBenchmark to run the microBenchmarks.ClassBaselineBenchmark suite in isolation with a high iteration count. This causes large amounts of memory usage in SpiderMonkey but not V8.

Comment 1

[Julian Seward [:jseward]]

Initial investigation suggests gradle jsShell_wasmSingleBenchmark uses
excessive memory while allocating gc-arrays with 80KB payload areas.
However, the following does not show the problem:

   (type $tArrayI64 (array i64))
   (func (export "go")
     (local $i i32)
     (loop $cont
       (array.new $tArrayI64 (i64.const 1337) (i32.const 10000))
       drop
       (local.set $i (i32.add (local.get $i) (i32.const 1)))
       (br_if $cont (i32.lt_u (local.get $i) (i32.const 10000000)))
     )
   )

Comment 2

[Julian Seward [:jseward]]

Attachment: standalone.tar.bz2

Here's a standalone test case constructed from a snapshot of
./gradlew jsShell_wasmSingleBenchmark.
Simply untar and run the command specified in HOWTO_RUN.txt.
Does not require the Kotlin framework.

Comment 3

[Julian Seward [:jseward]]

Attachment: alloc_many3.js

A standalone (and minimal) test case that shows the problem and that explains why the problem happens.

Comment 4

[Julian Seward [:jseward]]

Attachment: bug1855732-1-PaU7-in-WSO-WAO.diff-5

Comment 5

[Julian Seward [:jseward]]

Attachment: bug1855732-3-connect-to-plumbing.diff-5

Comment 6

[Julian Seward [:jseward]]

When applied to a tree that has the fix from the now-landed bug 1858200, the
patches in comment 4 and comment 5 fix the problem on all targets and fairly
accurately show the costs entailed by the fix. However, they are excessively
complex and so are unlikely to be the final implementation.

Comment 7

[Julian Seward [:jseward]]

Attachment: Bug 1855732 - Make wasm-gc trailer sizes available to the tenured-heap's when-to-GC decision-making machinery. r=rhunt.

For trailer blocks whose owning Wasm{Struct,Array}Objects make it into the
tenured heap, we have to tell the tenured heap how big those trailers are in
order to get major GCs to happen sufficiently frequently. If we don't do
that, programs that allocate many such objects with big trailers can end up
with wildly excessive space use, because the tenured heap's when-to-GC
heuristics are unaware that each (relatively small) Wasm{Struct,Array}Object
is "shadowed" by a large amount of malloc'd space, and so major collection
happens far too infrequently.

The changes are simple -- they just notify the the tenured heap's accounting
system by calling AddCellMemory when an object enters the tenured heap and
GCContext::removeCellMemory when an object leaves the tenured heap (is
finalized).

Some comments have been updated.

As a ridealong, the bizarrely-misnamed MallocedBlockCache::allowSlow has
been renamed to ::allocSlow.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/069be1480d6f
Make wasm-gc trailer sizes available to the tenured-heap's when-to-GC decision-making machinery.  r=jonco.

Comment 9

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/069be1480d6f