Commit 684e784b authored by Dominik Inführ's avatar Dominik Inführ Committed by V8 LUCI CQ

[heap] Do not lock pending_allocation_mutex_ in CompactionSpaces

CompactionSpaces are only used during GC, so there is no need to
lock pending_allocation_mutex_ for them. Locking for GC allocations
actually caused multiple regressions.

Bug: chromium:1214765
Change-Id: I6db4ed96deced41dc52f04b2917ec944b4ccc674
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928189Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74896}
parent 501abfb7
......@@ -275,9 +275,10 @@ void PagedSpace::SetTopAndLimit(Address top, Address limit) {
Page::FromAddress(top) == Page::FromAddress(limit - 1));
BasicMemoryChunk::UpdateHighWaterMark(allocation_info_.top());
allocation_info_.Reset(top, limit);
base::SharedMutexGuard<base::kExclusive> guard(
&heap_->pending_allocation_mutex_);
// The order of the following two stores is important.
base::Optional<base::SharedMutexGuard<base::kExclusive>> optional_guard;
if (!is_local_space())
optional_guard.emplace(&heap_->pending_allocation_mutex_);
original_limit_ = limit;
original_top_ = top;
}
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment