This is likely a dup of issue 909723, but the included test case might make it easier to debug.

When looking at this bug, I noticed that there are a couple of global handles that hold on to state long enough to make page refreshed go out of memory. Some are devtools related but one instance where the wasm implementation is at fault is the handle to the imports of a module.

The imports object also contains a reference to the webassembly memory object (the default in generated emscripten code). Hence, keeping the module_import alive will also keep the memory alive. It now seems that on a page refresh, the handle in AsyncInstantiateCompileResultResolver is alive long enough that it blocks the allocation of the new memory and the page goes OOM.

Assigning to Clemens, as he is currently refactoring that area.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/148039e6a10f63739b12832235d5075ea72d23f0

commit 148039e6a10f63739b12832235d5075ea72d23f0
Author: Clemens Hammacher <clemensh@chromium.org>
Date: Tue Dec 11 18:06:23 2018

[wasm] Reset callbacks after last event

Callbacks can keep embedder objects alive, hence clear them after
delivering the final event.

R=ahaas@chromium.org

Bug: chromium:912764
Change-Id: I9ac739bbce32cb1026991610e0720210717c333e
Reviewed-on: https://chromium-review.googlesource.com/c/1371565
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58168}
[modify] https://crrev.com/148039e6a10f63739b12832235d5075ea72d23f0/src/wasm/compilation-environment.h
[modify] https://crrev.com/148039e6a10f63739b12832235d5075ea72d23f0/src/wasm/module-compiler.cc

#5 fixes some retaining paths via callbacks. We still run OOM though.
Back to Stephan to look at the other paths.

I just saw that we still keep the CompilationResultResolver alive as long as the AsyncCompileJob lives. We should fix that.
Taking the bug back for now :)