1569888 - JIT code memory accounting only tracks wasm stable tier code

Status: RESOLVED WONTFIX

(Core :: JavaScript: WebAssembly, defect)

Description

[Jon Coppeard (:jonco)]

Currently we only track JIT code memory used by stable tier code. Comments in WasmModuleObject::create say:

    // We account for the first tier here; the second tier, if different, will be
    // accounted for separately when it's been compiled.

I don't think this ever happens though. One problem is that a wasm Module is not associated with a single GC zone and I don't think there's a way to easily find the existing WasModuleObjects for a Module.

Comment 1

[Luke Wagner [:luke]]

So that the numbers balance out, could a short-term workaround be that, when freeing the non-stable tier of code, to not account it? Practically, this seems ok since the optimized code should be strictly smaller than the (correctly accounted) stable tier code so the accounting logic would only be off by a fixed factor.

Comment 2

[Jon Coppeard (:jonco)]

(In reply to Luke Wagner [:luke] from comment #1)
Yes, and that's what I'm planning to do initially.

The JIT code memory counter is mainly used as a backstop to prevent OOM so I'm wondering whether this should be made per-runtime rather than per-zone. That should solve the problem of associating a Module with a zone, at the cost of triggering a full GC rather than a zone GC.

Comment 3

[Jan de Mooij [:jandem]]

I wonder how useful this backstop is nowadays? We used to have those executable-code-OOM issues and Benjamin added the JIT code counter for that, but around the same time Luke added code to call the large-alloc-failure callback when we fail to allocate executable code for Wasm and that will trigger full GC/CCs too, at least in the browser...

Comment 4

[Luke Wagner [:luke]]

Because of postMessage()ing of Modules, wasm::Module and its code can be shared between multiple JSRuntimes. I expect simply not accounting for it will be fine due to the bumping of the counter for the stable tier + large-alloc-failure callback backstop.

Comment 5

[Jon Coppeard (:jonco)]

(In reply to Luke Wagner [:luke] from comment #4)
Thanks, I didn't realise that. In that case I think this is WONTFIX.