Make copyToVector() robust against conservative GCs.

Make copyToVector() robust against conservative GCs.

When resizing copyToVector()'s incoming vector to match the size of
the collection being copied from, do this in a manner that locks out
GCs across that vector backing store allocation.

If not, there's a risk that the collection's size might shrink across
that GC, and leave the vector as having an overestimated size.
copyToVector() will in that case unexpectedly encounter empty
elements in the tail, and fail.

This can only happen for Oilpan heap collections having weak references..
and that collection is not directly stack-reachable when a conservative
GC triggers. Rare, but copyToVector()'s obligation to make that safe
rather than its callers.

R=haraken
BUG=581698
Committed: https://crrev.com/f7ecadae84cdc1271ba7420844f143ea0e961590
Cr-Commit-Position: refs/heads/master@{#372693}

[sof, 2016-02-01 14:35:55]

The CQ bit was checked by sigbjornf@opera.com to run a CQ dry run

[sof, 2016-02-01 14:36:45]

sigbjornf@opera.com changed reviewers:
+ oilpan-reviews@chromium.org

[sof, 2016-02-01 14:36:45]

please take a look.

[commit-bot: I haz the power, 2016-02-01 14:36:46]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1652953002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1652953002/1

[commit-bot: I haz the power, 2016-02-01 14:51:40]

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

[commit-bot: I haz the power, 2016-02-01 14:51:41]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  chromeos_daisy_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)

[haraken, 2016-02-01 15:09:24]

LGTM

[sof, 2016-02-01 15:45:34]

The CQ bit was checked by sigbjornf@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-02-01 15:46:01]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1652953002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1652953002/20001

[commit-bot: I haz the power, 2016-02-01 16:57:26]

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

[commit-bot: I haz the power, 2016-02-01 16:57:27]

Dry run: This issue passed the CQ dry run.

[sof, 2016-02-01 18:17:09]

Description was changed from

==========
Make copyToVector() robust against conservative GCs.

When resizing copyToVector()'s incoming vector to match the size of
the collection being copied from, do this in a manner that locks out
GCs across that vector backing store allocation.

If not, there's a risk that the collection's size might shrink across
that GC, and leave the vector as having an overestimated size.
copyToVector() will in that case unexpectedly encounter empty
elements in the tail, and fail.

This can only happen for Oilpan heap collections having weak references..
and that collection is not directly stack-reachable when a conservative
GC triggers. Rare, but copyToVector()'s obligation to make that safe
rather than its callers.

R=
BUG=581698
==========

to

==========
Make copyToVector() robust against conservative GCs.

When resizing copyToVector()'s incoming vector to match the size of
the collection being copied from, do this in a manner that locks out
GCs across that vector backing store allocation.

If not, there's a risk that the collection's size might shrink across
that GC, and leave the vector as having an overestimated size.
copyToVector() will in that case unexpectedly encounter empty
elements in the tail, and fail.

This can only happen for Oilpan heap collections having weak references..
and that collection is not directly stack-reachable when a conservative
GC triggers. Rare, but copyToVector()'s obligation to make that safe
rather than its callers.

R=haraken
BUG=581698
==========

[sof, 2016-02-01 18:17:17]

The CQ bit was checked by sigbjornf@opera.com

[sof, 2016-02-01 18:17:18]

The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org
Link to the patchset: https://codereview.chromium.org/1652953002/#ps20001
(title: "remove unnecessary 'template' use")

[commit-bot: I haz the power, 2016-02-01 18:19:42]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1652953002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1652953002/20001

[commit-bot: I haz the power, 2016-02-01 18:29:31]

Description was changed from

==========
Make copyToVector() robust against conservative GCs.

When resizing copyToVector()'s incoming vector to match the size of
the collection being copied from, do this in a manner that locks out
GCs across that vector backing store allocation.

If not, there's a risk that the collection's size might shrink across
that GC, and leave the vector as having an overestimated size.
copyToVector() will in that case unexpectedly encounter empty
elements in the tail, and fail.

This can only happen for Oilpan heap collections having weak references..
and that collection is not directly stack-reachable when a conservative
GC triggers. Rare, but copyToVector()'s obligation to make that safe
rather than its callers.

R=haraken
BUG=581698
==========

to

==========
Make copyToVector() robust against conservative GCs.

When resizing copyToVector()'s incoming vector to match the size of
the collection being copied from, do this in a manner that locks out
GCs across that vector backing store allocation.

If not, there's a risk that the collection's size might shrink across
that GC, and leave the vector as having an overestimated size.
copyToVector() will in that case unexpectedly encounter empty
elements in the tail, and fail.

This can only happen for Oilpan heap collections having weak references..
and that collection is not directly stack-reachable when a conservative
GC triggers. Rare, but copyToVector()'s obligation to make that safe
rather than its callers.

R=haraken
BUG=581698
==========

[commit-bot: I haz the power, 2016-02-01 18:29:32]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-02-01 18:31:14]

Description was changed from

==========
Make copyToVector() robust against conservative GCs.

When resizing copyToVector()'s incoming vector to match the size of
the collection being copied from, do this in a manner that locks out
GCs across that vector backing store allocation.

If not, there's a risk that the collection's size might shrink across
that GC, and leave the vector as having an overestimated size.
copyToVector() will in that case unexpectedly encounter empty
elements in the tail, and fail.

This can only happen for Oilpan heap collections having weak references..
and that collection is not directly stack-reachable when a conservative
GC triggers. Rare, but copyToVector()'s obligation to make that safe
rather than its callers.

R=haraken
BUG=581698
==========

to

==========
Make copyToVector() robust against conservative GCs.

When resizing copyToVector()'s incoming vector to match the size of
the collection being copied from, do this in a manner that locks out
GCs across that vector backing store allocation.

If not, there's a risk that the collection's size might shrink across
that GC, and leave the vector as having an overestimated size.
copyToVector() will in that case unexpectedly encounter empty
elements in the tail, and fail.

This can only happen for Oilpan heap collections having weak references..
and that collection is not directly stack-reachable when a conservative
GC triggers. Rare, but copyToVector()'s obligation to make that safe
rather than its callers.

R=haraken
BUG=581698

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

[commit-bot: I haz the power, 2016-02-01 18:31:15]

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