Lock CrossThreadPersistentRegion until end of weak processing.

Lock CrossThreadPersistentRegion until end of weak processing.

Allocating & releasing a CrossThread(Weak)Persistent is something that
all threads are currently allowed, even those not attached to Oilpan and
having no heap of their own. It is however not safe for the set of
CrossThreadPersistents to be altered while a garbage collection is
underway.

Not just while the set of registered persistents are being marked and
traced, but up until and including the processing of weak (persistent)
references that happen after marking. If not, a thread would be able to
release a CrossThreadWeakPersistent node which the weak processing separately
maintains a pointer to, clearing & freeing its allocation. Which would
cause havoc, hence we impose a lock on CrossThreadPersistentRegion while
the marking and global weak processing is being performed -- any thread
attempting to create or free cross-thread persistents will be locked out
for the duration.

Following r396432, the use of CrossThreadPersistents from non-attached threads
has been reduced greatly and is slight.

R=
BUG=610477
Committed: https://crrev.com/174054b089b91ea41c4baa09bcc7b6762fe42005
Cr-Commit-Position: refs/heads/master@{#396540}

[sof, 2016-05-26 21:27:31]

Description was changed from

==========
Lock CrossThreadPersistentRegion while marking.

R=
BUG=610477
==========

to

==========
Lock CrossThreadPersistentRegion until end of weak processing

R=
BUG=610477
==========

[sof, 2016-05-26 21:27:50]

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

[sof, 2016-05-26 21:27:51]

please take a look.

[haraken, 2016-05-26 21:54:18]

LGTM, but would you help me understand why we need to grab a lock until the end
of weak processing? Are you concerned that a non-attached thread creates a new
CrossThreadPersistent while attached threads are in the stop-the-world phase?

[sof, 2016-05-27 05:12:46]

On 2016/05/26 21:54:18, haraken wrote:
> LGTM, but would you help me understand why we need to grab a lock until the
end
> of weak processing? Are you concerned that a non-attached thread creates a new
> CrossThreadPersistent while attached threads are in the stop-the-world phase?

Clearing & releasing a CTWP is something that thread is allowed to do, which
risks clearing memory that the weak callback (handleWeakCell()) works over.
https://bugs.chromium.org/p/chromium/issues/detail?id=610477#c10 explains more.

[sof, 2016-05-27 19:49:37]

Description was changed from

==========
Lock CrossThreadPersistentRegion until end of weak processing

R=
BUG=610477
==========

to

==========
Lock CrossThreadPersistentRegion until end of weak processing.

Allocating & releasing a CrossThread(Weak)Persistent is something that
all threads are currently allowed, even those not attached to Oilpan and
having no heap of their own. It is however not safe for the set of
CrossThreadPersistents to be altered while a garbage collection is
underway.

Not just while the set of registered persistents are being marked and
traced, but up until and including the processing of weak (persistent)
references that happen after marking. If not, a thread would be able to
release a CrossThreadWeakPersistent node which the weak processing separately
maintains a pointer to, clearing & freeing its allocation. Which would
cause havoc, hence we impose a lock on CrossThreadPersistentRegion while
the marking and global weak processing is being performed -- any thread
attempting to create or free cross-thread persistents will be locked out
for the duration.

Following r396432, the use of CrossThreadPersistents from non-attached threads
has been reduced greatly and is slight.

R=
BUG=610477
==========

[sof, 2016-05-27 19:49:45]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2016-05-27 19:50:11]

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

[commit-bot: I haz the power, 2016-05-27 19:54:30]

Description was changed from

==========
Lock CrossThreadPersistentRegion until end of weak processing.

Allocating & releasing a CrossThread(Weak)Persistent is something that
all threads are currently allowed, even those not attached to Oilpan and
having no heap of their own. It is however not safe for the set of
CrossThreadPersistents to be altered while a garbage collection is
underway.

Not just while the set of registered persistents are being marked and
traced, but up until and including the processing of weak (persistent)
references that happen after marking. If not, a thread would be able to
release a CrossThreadWeakPersistent node which the weak processing separately
maintains a pointer to, clearing & freeing its allocation. Which would
cause havoc, hence we impose a lock on CrossThreadPersistentRegion while
the marking and global weak processing is being performed -- any thread
attempting to create or free cross-thread persistents will be locked out
for the duration.

Following r396432, the use of CrossThreadPersistents from non-attached threads
has been reduced greatly and is slight.

R=
BUG=610477
==========

to

==========
Lock CrossThreadPersistentRegion until end of weak processing.

Allocating & releasing a CrossThread(Weak)Persistent is something that
all threads are currently allowed, even those not attached to Oilpan and
having no heap of their own. It is however not safe for the set of
CrossThreadPersistents to be altered while a garbage collection is
underway.

Not just while the set of registered persistents are being marked and
traced, but up until and including the processing of weak (persistent)
references that happen after marking. If not, a thread would be able to
release a CrossThreadWeakPersistent node which the weak processing separately
maintains a pointer to, clearing & freeing its allocation. Which would
cause havoc, hence we impose a lock on CrossThreadPersistentRegion while
the marking and global weak processing is being performed -- any thread
attempting to create or free cross-thread persistents will be locked out
for the duration.

Following r396432, the use of CrossThreadPersistents from non-attached threads
has been reduced greatly and is slight.

R=
BUG=610477
==========

[commit-bot: I haz the power, 2016-05-27 19:54:32]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-05-27 19:57:43]

Description was changed from

==========
Lock CrossThreadPersistentRegion until end of weak processing.

Allocating & releasing a CrossThread(Weak)Persistent is something that
all threads are currently allowed, even those not attached to Oilpan and
having no heap of their own. It is however not safe for the set of
CrossThreadPersistents to be altered while a garbage collection is
underway.

Not just while the set of registered persistents are being marked and
traced, but up until and including the processing of weak (persistent)
references that happen after marking. If not, a thread would be able to
release a CrossThreadWeakPersistent node which the weak processing separately
maintains a pointer to, clearing & freeing its allocation. Which would
cause havoc, hence we impose a lock on CrossThreadPersistentRegion while
the marking and global weak processing is being performed -- any thread
attempting to create or free cross-thread persistents will be locked out
for the duration.

Following r396432, the use of CrossThreadPersistents from non-attached threads
has been reduced greatly and is slight.

R=
BUG=610477
==========

to

==========
Lock CrossThreadPersistentRegion until end of weak processing.

Allocating & releasing a CrossThread(Weak)Persistent is something that
all threads are currently allowed, even those not attached to Oilpan and
having no heap of their own. It is however not safe for the set of
CrossThreadPersistents to be altered while a garbage collection is
underway.

Not just while the set of registered persistents are being marked and
traced, but up until and including the processing of weak (persistent)
references that happen after marking. If not, a thread would be able to
release a CrossThreadWeakPersistent node which the weak processing separately
maintains a pointer to, clearing & freeing its allocation. Which would
cause havoc, hence we impose a lock on CrossThreadPersistentRegion while
the marking and global weak processing is being performed -- any thread
attempting to create or free cross-thread persistents will be locked out
for the duration.

Following r396432, the use of CrossThreadPersistents from non-attached threads
has been reduced greatly and is slight.

R=
BUG=610477

Committed: https://crrev.com/174054b089b91ea41c4baa09bcc7b6762fe42005
Cr-Commit-Position: refs/heads/master@{#396540}
==========

[commit-bot: I haz the power, 2016-05-27 19:57:44]

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