[wasm] Fix GC memory leak in Wasm interpreter [v8/v8 : main]
Emmanuel Romero Ruiz (Gerrit)
Emmanuel Romero Ruiz added 1 comment![]( "Open in Gerrit")
Related details
- Daniel Lehmann
- Paolo Severini
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Daniel Lehmann (Gerrit)
Daniel Lehmann voted and added 1 comment![]( "Open in Gerrit")
Votes added by Daniel Lehmann
| Code-Review | +1 |
1 comment
Rubber stamping this Drumbrake-only change as usual. But since I'm not a GC expert, I think it would be beneficial to discuss this (or at least CC) the GC team, hence adding Michael Lippauz.
Also more generally / background info: How was this discovered? Would Edge using DrumBrake reliably OOM, e.g., on WasmGC-heavy Dart or Kotlin applications? (say https://chromium-workloads.web.app/jetstream/main/?test=Dart-flute-todomvc-wasm in the upcoming JetStream 3 benchmark)?
Related details
- Paolo Severini
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Michael Lippautz (Gerrit)
Michael Lippautz added 1 comment![]( "Open in Gerrit")
- V8 inflates the old space allocation limit (observed: 16MB → 1389MB)This seems wrong. The maximum growing factor is 4x give or take. With 16M live size this should be ~64M for the next GC.
Can you provide a log with `--trace-gc,--trace-gc-verbose` ?
Related details
- Paolo Severini
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Paolo Severini (Gerrit)
Paolo Severini added 2 comments![]( "Open in Gerrit")
Rubber stamping this Drumbrake-only change as usual. But since I'm not a GC expert, I think it would be beneficial to discuss this (or at least CC) the GC team, hence adding Michael Lippauz.
Also more generally / background info: How was this discovered? Would Edge using DrumBrake reliably OOM, e.g., on WasmGC-heavy Dart or Kotlin applications? (say https://chromium-workloads.web.app/jetstream/main/?test=Dart-flute-todomvc-wasm in the upcoming JetStream 3 benchmark)?
This issue was raised by the Google Sheets team, which noticed an increase of OOM crashes only on Edge, which we our telemetry mapped to the use of the Wasm interpreter.
I could easily reproduce the issue running Google Sheets Edge with the interpreter enabled (with the V8 heap usage increasing ~20MB/sec).
Initially I thought that the problem could be related to the way ref objects are managed and that the leak might be caused by handles accumulating in the HandleScope for some long-running function. But even after a very long refactoring, the problem was still there, and I realized that the issue disappeared if the interpreter periodically triggered GCs during stack checks. This made me think that the problem could be related to some GC heuristics that does not work well with wasmgc code that runs relatively slowly and allocates a lot of objects.
- V8 inflates the old space allocation limit (observed: 16MB → 1389MB)This seems wrong. The maximum growing factor is 4x give or take. With 16M live size this should be ~64M for the next GC.
Can you provide a log with `--trace-gc,--trace-gc-verbose` ?
The comment maybe is imprecise, the allocation limit does not grow immediately from 16MB to 1.4GB, it happens through time.
I will try to generate a log with `--trace-gc,--trace-gc-verbose`. Google Sheets is a very large application; I will also try with the Dart JetStream 3 workload, which should be more manageable.
Related details
- Michael Lippautz
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |