Issue 794200  has been merged into this issue.

This issue has appeared again in  https://crbug.com/794200 . There is another repro test case on that bug too.

Eric, I'll take a look if you don't mind.

I looked at the leak in https://takahirox.github.io/WebAssembly-benchmark/

For some reason the leak happens only if the DevTools is open.

Looks like something in DevTools (maybe console?) is keeping a strong handle to each Wasm Script object.

Each script object then retains the wasm_compiled_module, which a fixed array of length 21.

The second element of that array retains a native context, which then retains a global object.

The "module" property of the global object retains a JSObject, which then retains the array buffer in the "buffer" property.

I have two questions:
1) Is it expected that DevTools retains script objects?
2) Is it expected that wasm script object retains a wasm module, which then retains the native context?

The second part seems to be the real issue to me. Ordinary scripts do not retain native contexts.

Yes, both is actually expected. I think though that 2) can be eliminated by holding a weak reference to the native context. We only need to access this while the module is being executed, and that context should stay alive at least as long as we execute something.
Would that context die without the reference we currently hold?

Oh, and thanks for that analysis! Helps a lot to understand what's going on.

Discussed this offline with Clemens. A quick fix would be to make the native context link weak. The native context should be retained at the call site of the wasm code during execution.

Thanks, all, for investigating this!

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

commit 9c858492e988399cb748bc33c1296e198be103a1
Author: Clemens Hammacher <clemensh@chromium.org>
Date: Mon Dec 18 11:57:00 2017

[wasm] Move more methods to WasmSharedModuleData

Many methods currently defined in WasmCompiledModule actually only use
shared information from WasmSharedModuleData. Hence, move them to this
class.

R=ahaas@chromium.org

Bug:  chromium:750256 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia298306c3757fca8e2d93eaaf3424d6f91150212
Reviewed-on: https://chromium-review.googlesource.com/831509
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50156}
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/src/api.cc
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/src/frames.cc
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/src/isolate.cc
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/src/messages.cc
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/src/objects.cc
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/src/runtime/runtime-debug.cc
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/src/wasm/module-compiler.cc
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/src/wasm/wasm-debug.cc
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/src/wasm/wasm-module.cc
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/src/wasm/wasm-module.h
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/src/wasm/wasm-objects.cc
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/src/wasm/wasm-objects.h
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/test/cctest/wasm/test-run-wasm-module.cc
[modify] https://crrev.com/9c858492e988399cb748bc33c1296e198be103a1/test/cctest/wasm/test-wasm-breakpoints.cc

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

commit 70c36588065ccf18474138015063ec06fd5d5d96
Author: Clemens Hammacher <clemensh@chromium.org>
Date: Mon Dec 18 18:07:09 2017

[wasm] Store native context in weak link

The WasmCompiledModule is kept alive from the Script, which again is
kept alive then the debugger is enabled. This, however, should not keep
the whole context alive, including the global object.
Hence, we only store a weak reference to the native context.

R=ahaas@chromium.org

Bug:  chromium:750256 
Change-Id: Ia409995c40fb3e90665534fbc94c6eafc081c4e5
Reviewed-on: https://chromium-review.googlesource.com/832126
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50174}
[modify] https://crrev.com/70c36588065ccf18474138015063ec06fd5d5d96/src/wasm/module-compiler.cc
[modify] https://crrev.com/70c36588065ccf18474138015063ec06fd5d5d96/src/wasm/wasm-objects.cc
[modify] https://crrev.com/70c36588065ccf18474138015063ec06fd5d5d96/src/wasm/wasm-objects.h

Thank you !
Do you have a target version for when this will be available in Chrome ?

This will be fixed in all future releases of chrome, starting tomorrow.

It will not make it to M64, but it will be in the stable release of M65.

Fantastic. Thank you !