[wasm] Fix wasm instantiation flakes

[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
Committed: https://crrev.com/b75a0c4a555278de8c59695e55f26a4e2ea6c862
Cr-Commit-Position: refs/heads/master@{#40126}

[Mircea Trofin, 2016-10-06 05:54:12]

The CQ bit was checked by mtrofin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-06 05:54:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mircea Trofin, 2016-10-06 06:04:31]

Description was changed from

==========
[wasm] fix flaky asm-wasm

BUG=
==========

to

==========
[wasm] fix flaky asm-wasm

The spurious failures were caused by collection of compiled module
template between time we get its code object array and time we 
determine if it was owned. In turn, this meant that we didn't use the
correct address for patching references to globals.

I plan to make a more substantial change to improve the robustness
of the instance management, by upfronting all "data collection" phases. 
For now, this change should remove the flake.

BUG=v8:5451
==========

[Mircea Trofin, 2016-10-06 06:04:32]

mtrofin@chromium.org changed reviewers:
+ bradnelson@chromium.org, titzer@chromium.org

[commit-bot: I haz the power, 2016-10-06 06:32:59]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-06 06:33:00]

Dry run: This issue passed the CQ dry run.

[Mircea Trofin, 2016-10-06 06:43:26]

Description was changed from

==========
[wasm] fix flaky asm-wasm

The spurious failures were caused by collection of compiled module
template between time we get its code object array and time we 
determine if it was owned. In turn, this meant that we didn't use the
correct address for patching references to globals.

I plan to make a more substantial change to improve the robustness
of the instance management, by upfronting all "data collection" phases. 
For now, this change should remove the flake.

BUG=v8:5451
==========

to

==========
[wasm] fix flaky asm-wasm

The spurious failures were caused by finalization of compiled module
template between time we get its code object array and time we 
determine if it was owned. In turn, this meant that we didn't use the
correct address for patching references to globals.

I plan to make a more substantial change to improve the robustness
of the instance management, by upfronting all "data collection" phases. 
For now, this change should remove the flake.

BUG=v8:5451
==========

[titzer, 2016-10-07 12:40:32]

https://codereview.chromium.org/2395063002/diff/1/src/wasm/wasm-module.cc
File src/wasm/wasm-module.cc (right):

https://codereview.chromium.org/2395063002/diff/1/src/wasm/wasm-module.cc#new...
src/wasm/wasm-module.cc:1215: WeakCell* tmp =
original->ptr_to_weak_owning_instance();
Why do we have a raw pointer here?

https://codereview.chromium.org/2395063002/diff/1/src/wasm/wasm-module.cc#new...
src/wasm/wasm-module.cc:1221: code_table =
factory->CopyFixedArray(old_code_table);
I don't understand how this fixes anything. As far as I can tell, it just moves
an allocation until after the check.

[Mircea Trofin, 2016-10-07 14:44:24]

https://codereview.chromium.org/2395063002/diff/1/src/wasm/wasm-module.cc
File src/wasm/wasm-module.cc (right):

https://codereview.chromium.org/2395063002/diff/1/src/wasm/wasm-module.cc#new...
src/wasm/wasm-module.cc:1215: WeakCell* tmp =
original->ptr_to_weak_owning_instance();
On 2016/10/07 12:40:32, titzer wrote:
> Why do we have a raw pointer here?

Not sure, I think this is from 0xC; it's immaterial, though, it seems
to be used for a check only and then we fetch the owner, neither are
GC-ing.

https://codereview.chromium.org/2395063002/diff/1/src/wasm/wasm-module.cc#new...
src/wasm/wasm-module.cc:1221: code_table =
factory->CopyFixedArray(old_code_table);
On 2016/10/07 12:40:32, titzer wrote:
> I don't understand how this fixes anything. As far as I can tell, it just
moves
> an allocation until after the check. 

Consider the old code. Suppose the allocation on line 1217 triggers GC for
{original}'s owner. As a result, the weak link to the owner is reset by the
InstanceFinalizer. We want to do that because that is how we then determine if a
compiled module is owned or not. 

{owner} will be uninitialized, because we're not cloning.

Now, when looking to relocate globals, we will believe the old globals address
is nullptr (incorrect), and fail to patch the code.

The change ensures we catch the owner before any of this happens.

As I mentioned, I'm working on a more involved change, to avoid such
inconsistencies "once and for all".

[titzer, 2016-10-07 15:37:42]

https://codereview.chromium.org/2395063002/diff/1/src/wasm/wasm-module.cc
File src/wasm/wasm-module.cc (right):

https://codereview.chromium.org/2395063002/diff/1/src/wasm/wasm-module.cc#new...
src/wasm/wasm-module.cc:1221: code_table =
factory->CopyFixedArray(old_code_table);
On 2016/10/07 14:44:23, Mircea Trofin wrote:
> On 2016/10/07 12:40:32, titzer wrote:
> > I don't understand how this fixes anything. As far as I can tell, it just
> moves
> > an allocation until after the check. 
> 
> Consider the old code. Suppose the allocation on line 1217 triggers GC for
> {original}'s owner. As a result, the weak link to the owner is reset by the
> InstanceFinalizer. We want to do that because that is how we then determine if
a
> compiled module is owned or not. 
> 
> {owner} will be uninitialized, because we're not cloning.
> 
> Now, when looking to relocate globals, we will believe the old globals address
> is nullptr (incorrect), and fail to patch the code.
> 
> The change ensures we catch the owner before any of this happens.
> 
> As I mentioned, I'm working on a more involved change, to avoid such
> inconsistencies "once and for all".

Ok, until then can we have a switch to turn off this optimization until it's
fully stabilized? It's caused lots of gc-stress failures and resisted many
attempts to fix it so far.

[Mircea Trofin, 2016-10-07 15:49:43]

On 2016/10/07 15:37:42, titzer wrote:
> https://codereview.chromium.org/2395063002/diff/1/src/wasm/wasm-module.cc
> File src/wasm/wasm-module.cc (right):
> 
>
https://codereview.chromium.org/2395063002/diff/1/src/wasm/wasm-module.cc#new...
> src/wasm/wasm-module.cc:1221: code_table =
> factory->CopyFixedArray(old_code_table);
> On 2016/10/07 14:44:23, Mircea Trofin wrote:
> > On 2016/10/07 12:40:32, titzer wrote:
> > > I don't understand how this fixes anything. As far as I can tell, it just
> > moves
> > > an allocation until after the check. 
> > 
> > Consider the old code. Suppose the allocation on line 1217 triggers GC for
> > {original}'s owner. As a result, the weak link to the owner is reset by the
> > InstanceFinalizer. We want to do that because that is how we then determine
if
> a
> > compiled module is owned or not. 
> > 
> > {owner} will be uninitialized, because we're not cloning.
> > 
> > Now, when looking to relocate globals, we will believe the old globals
address
> > is nullptr (incorrect), and fail to patch the code.
> > 
> > The change ensures we catch the owner before any of this happens.
> > 
> > As I mentioned, I'm working on a more involved change, to avoid such
> > inconsistencies "once and for all".
> 
> Ok, until then can we have a switch to turn off this optimization until it's
> fully stabilized? It's caused lots of gc-stress failures and resisted many
> attempts to fix it so far.

You mean, go back to having full GC before instantiating? Yes.

[Mircea Trofin, 2016-10-07 18:15:15]

The CQ bit was checked by mtrofin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-07 18:15:19]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mircea Trofin, 2016-10-07 18:27:05]

Description was changed from

==========
[wasm] fix flaky asm-wasm

The spurious failures were caused by finalization of compiled module
template between time we get its code object array and time we 
determine if it was owned. In turn, this meant that we didn't use the
correct address for patching references to globals.

I plan to make a more substantial change to improve the robustness
of the instance management, by upfronting all "data collection" phases. 
For now, this change should remove the flake.

BUG=v8:5451
==========

to

==========
[wasm] fix flaky asm-wasm

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
==========

[Mircea Trofin, 2016-10-07 18:28:09]

Description was changed from

==========
[wasm] fix flaky asm-wasm

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
==========

to

==========
[wasm] fix flaky asm-wasm

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
==========

[commit-bot: I haz the power, 2016-10-07 18:52:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-07 18:52:32]

Dry run: This issue passed the CQ dry run.

[Mircea Trofin, 2016-10-07 20:27:57]

The CQ bit was checked by mtrofin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-07 20:27:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mircea Trofin, 2016-10-07 21:00:18]

Patchset #2 (id:20001) has been deleted

[commit-bot: I haz the power, 2016-10-07 21:06:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-07 21:06:59]

Dry run: This issue passed the CQ dry run.

[Mircea Trofin, 2016-10-07 21:12:12]

The CQ bit was checked by mtrofin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-07 21:12:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mircea Trofin, 2016-10-07 21:19:45]

Description was changed from

==========
[wasm] fix flaky asm-wasm

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
==========

to

==========
[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
==========

[commit-bot: I haz the power, 2016-10-07 21:45:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-07 21:45:44]

Dry run: This issue passed the CQ dry run.

[titzer, 2016-10-08 09:39:57]

On 2016/10/07 15:49:43, Mircea Trofin wrote:
> On 2016/10/07 15:37:42, titzer wrote:
> > https://codereview.chromium.org/2395063002/diff/1/src/wasm/wasm-module.cc
> > File src/wasm/wasm-module.cc (right):
> > 
> >
>
https://codereview.chromium.org/2395063002/diff/1/src/wasm/wasm-module.cc#new...
> > src/wasm/wasm-module.cc:1221: code_table =
> > factory->CopyFixedArray(old_code_table);
> > On 2016/10/07 14:44:23, Mircea Trofin wrote:
> > > On 2016/10/07 12:40:32, titzer wrote:
> > > > I don't understand how this fixes anything. As far as I can tell, it
just
> > > moves
> > > > an allocation until after the check. 
> > > 
> > > Consider the old code. Suppose the allocation on line 1217 triggers GC for
> > > {original}'s owner. As a result, the weak link to the owner is reset by
the
> > > InstanceFinalizer. We want to do that because that is how we then
determine
> if
> > a
> > > compiled module is owned or not. 
> > > 
> > > {owner} will be uninitialized, because we're not cloning.
> > > 
> > > Now, when looking to relocate globals, we will believe the old globals
> address
> > > is nullptr (incorrect), and fail to patch the code.
> > > 
> > > The change ensures we catch the owner before any of this happens.
> > > 
> > > As I mentioned, I'm working on a more involved change, to avoid such
> > > inconsistencies "once and for all".
> > 
> > Ok, until then can we have a switch to turn off this optimization until it's
> > fully stabilized? It's caused lots of gc-stress failures and resisted many
> > attempts to fix it so far.
> 
> You mean, go back to having full GC before instantiating? Yes.

I think we have to avoid doing an explicit GC.

[Mircea Trofin, 2016-10-10 06:09:20]

Gentle reminder - ptal.

I re-ran the stress tests a few times. All green, 
consistently, except for the arm64 timeout, which appears to 
be a shard over-capacity. Locally, the shard repro command
passes.

[titzer, 2016-10-10 08:34:35]

lgtm

[Mircea Trofin, 2016-10-10 14:25:46]

The CQ bit was checked by mtrofin@chromium.org

[commit-bot: I haz the power, 2016-10-10 14:25:54]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-10 14:53:52]

Description was changed from

==========
[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
==========

to

==========
[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
==========

[commit-bot: I haz the power, 2016-10-10 14:53:53]

Committed patchset #3 (id:60001)

[commit-bot: I haz the power, 2016-10-10 14:54:02]

Description was changed from

==========
[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
==========

to

==========
[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

Committed: https://crrev.com/b75a0c4a555278de8c59695e55f26a4e2ea6c862
Cr-Commit-Position: refs/heads/master@{#40126}
==========

[commit-bot: I haz the power, 2016-10-10 14:54:03]

Patchset 3 (id:??) landed as
https://crrev.com/b75a0c4a555278de8c59695e55f26a4e2ea6c862
Cr-Commit-Position: refs/heads/master@{#40126}