[wasm] Fix wasm instantiation flakes
The spurious failures were caused by the compiled module template and its corresponding owning object getting out of sync due to memory allocations (which may trigger GC) between the points each were fetched. Specifically, the {original} was first obtained; then a GC may happen when cloning the {code_table}. At this point, the {original}'s owner may have been collected, getting us down the path of not cloning. When time comes to patch up globals, we incorrectly try to patch them assuming the global start is at 0 (nullptr), which in fact it isn't. This change roots early, in a GC-free area, both objects. Additionally, it avoids publishing to the instances chain the new instance until the very end. This way: - the objects used to create the new instance offer a consistent view - the instances chain does not see the object we try to form. If something fails, we can safely retry. - since the owner is rooted, the state of the front of the instances chain stays unchanged - with the same compiled module we started from. So the early belief that we needed to clone is not invalidated by any interspersed GC. This situation suffers from a sub-optimality discussed in the design document, in that, in a memory constrained system, the following snippet may surprisingly fail: var m = new WebAssembly.Module(...); var i1 = new WebAssembly.Instance(m); i1 = null; var i2 = new WebAssembly.Instance(m); //may fail. This will be addressed subsequently. BUG=v8:5451 Review-Url: https://codereview.chromium.org/2395063002 Cr-Commit-Position: refs/heads/master@{#40126}
Showing
Please
register
or
sign in
to comment