commits.txt

commit b9fa77b45d0f7d7d4847d60361621e1573cac9bb
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Fri May 24 12:03:30 2024 +0200

    [heap] Move marking bit into separate byte for traced handles
    
    This CL moves the markbit from the flags_ field into a separate
    boolean field. This should not regress the size of TracedNode on
    either 32- or 64-bit architectures as we still use 2 words for a
    TracedNode. With this change the flags are now main thread only and
    do not need use atomic accesses anymore.
    
    This CL should also fix a data race where is_in_use() was used
    non-atomically in a DCHECK while the concurrent marker set the mark
    bit concurrently.
    
    Bug: 340789840
    Change-Id: I73fa6e9cc22fa3a6fc1d54922114911f9bb0db3a
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5569191
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#94072}

commit f426e631e07945be2ba69dca0778801c1f976e80
Author: Clemens Backes <clemensb@chromium.org>
Date:   Thu Apr 4 15:26:35 2024 +0200

    Reland "[wasm] Also cache smaller code, after 2s delay"
    
    This is a reland of commit 27a0f364839889c194cb083cb4c1cd32c1ad284f.
    We now set the hard threshold in more tests to trigger immediate
    caching and avoid data races.
    
    Original change's description:
    > [wasm] Also cache smaller code, after 2s delay
    >
    > Finch experimentation showed that all more aggressive caching strategies
    > improve hit rates dramatically. We have to balance that against
    > increased time for serializing the module though.
    > Reducing the hard threshold results in pauses during background
    > compilation, hence we keep that at 1MB and additionally cache after 1kB
    > of new Turbofan code has been compiled, but no new code within 2
    > seconds.
    >
    > The latter two numbers don't seem to matter too much, but when
    > increasing the delay too much we see an increase of serialization
    > times on the highest percentiles, so keep it pretty low. This also
    > ensures that we still cache something if the user navigates away
    > after a few seconds.
    >
    > R=ahaas@chromium.org
    >
    > Bug: v8:14411
    > Change-Id: I67398acec39d29331fbd2428eec2f9387eeeb26a
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5412938
    > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > Commit-Queue: Clemens Backes <clemensb@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#93156}
    
    Bug: v8:14411
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_dbg
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
    Change-Id: I30acd82f94147c06646c0eca4e79a6ccc20b9102
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5423428
    Reviewed-by: Andreas Haas <ahaas@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#93170}

commit 80aef2091884c9cdec53f552e8c226ef87261285
Author: Andreas Haas <ahaas@chromium.org>
Date:   Wed Mar 20 15:47:46 2024 +0100

    [test][asmjs] Avoid data race in test by increasing sampling interval
    
    There seems to be a data race in the CPU profiler when two samples get
    collected at the same time. This happens in tests where samples get
    collected explicitly through a test API, in addition to the samples that
    get collected periodically by the profiler.
    
    With this CL we increase the sampling interval of the profiler, so that
    the test finishes before the profiler wants to collect its sample.
    
    This CL also reverts a fix that was attempted before but does not, as
    far as I understand help in all cases.
    
    R=jkummerow@chromium.org
    
    Bug: v8:14549
    Change-Id: I9608776065f30f7f98040f418235e1ca60f8deae
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5383508
    Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
    Commit-Queue: Andreas Haas <ahaas@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#92938}

commit 6fc3eab3c572770325e0617c1dc24173c20ab048
Author: Andreas Haas <ahaas@chromium.org>
Date:   Tue Mar 19 10:37:10 2024 +0100

    [profiler] Avoid data race in test by increasing sampling interval
    
    There seems to be a data race in the CPU profiler when two samples get
    collected at the same time. This happens in tests where samples get
    collected explicitly through a test API, in addition to the samples that
    get collected periodically by the profiler.
    
    With this CL we increase the sampling interval of the profiler, so that
    the test finishes before the profiler wants to collect its sample.
    
    R=cbruni@chromium.org
    
    Bug: v8:14549
    Change-Id: Ie7678961e6b10a5250b2460b79a046f9c6b864ea
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5377871
    Auto-Submit: Andreas Haas <ahaas@chromium.org>
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Commit-Queue: Andreas Haas <ahaas@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#92887}

commit f9c2749c41b4c2a7dbbba8849933f2cc0bad32f9
Author: Andreas Haas <ahaas@chromium.org>
Date:   Tue Feb 20 14:39:02 2024 +0100

    [wasm] Fix data race in EstimateCurrentMemoryConsumption
    
    The TypeFeedbackStorage was accessed concurrently by compilation on a
    background thread and the GC on the main thread in
    EstimateCurrentMemoryConsumption. This CL moves the access in
    EstimateCurrentMemoryConsumption behind a lock.
    
    R=mliedtke@chromium.org
    
    Bug: v8:14631
    Change-Id: I309614433824eaa2429e99f4aa8d6d532933ecc3
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5309914
    Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
    Commit-Queue: Andreas Haas <ahaas@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#92428}

commit 4b41b926e7292d75a1101ac5bc49c605ae1a8da3
Author: Clemens Backes <clemensb@chromium.org>
Date:   Mon Feb 5 14:37:10 2024 +0100

    [wasm] Fix data race when growing WasmDispatchTable
    
    Use acquire load from the GC thread and release store from the main
    thread when growing a table in-place.
    
    R=omerkatz@chromium.org
    
    Bug: v8:14608
    Change-Id: I252bef13772c2db4c23545432b632859f56009ff
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5268604
    Reviewed-by: Omer Katz <omerkatz@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#92199}

commit 769d7ab5ced2d3a1a7c04db169dda2468d326012
Author: Marja Hölttä <marja@chromium.org>
Date:   Tue Jan 30 16:16:17 2024 +0100

    [isolate] Fix a data race with the allow_compile_hints_magic_ cache
    
    Background inline streaming threads might read the value before its
    available, and race with setting the value.
    
    We can't delay background inline streaming until the value is surely
    available, so, handle the data race gracefully.
    
    Bug: chromium:1519976
    Change-Id: I6e8ebce47ad3918dad12ba11f7b0c318d32b5a7a
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5250112
    Commit-Queue: Marja Hölttä <marja@chromium.org>
    Reviewed-by: Victor Gomes <victorgomes@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#92116}

commit c68d7fb0e8e6eef55d2f9a56571c282fe1c991b3
Author: Clemens Backes <clemensb@chromium.org>
Date:   Fri Jan 12 12:02:01 2024 +0100

    [gc] Fix two more data races around EstimateCurrentMemoryConsumption
    
    One in the type canonicalizer, one in the compilation state.
    
    R=jkummerow@chromium.org
    
    Bug: chromium:1517559
    Change-Id: If39bce3fdc178785ee1ae7d67f5bbe89b55ae8fa
    Fixed: v8:14557
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5190456
    Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#91815}

commit 61c254f0dc3ed12f45c219e585eceb910edf4775
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Thu Dec 7 10:07:45 2023 +0100

    [heap] NotifyPossibleGarbage() needs to run on main thread
    
    This method always needs to run on the isolate's main thread because
    MemoryReducer is not thread-safe. The data race was introduced
    when background threads also started to invoke
    StartIncrementalMarkingIfAllocationLimitIsReached().
    
    Bug: chromium:1503063, chromium:1480975
    Change-Id: I4c474adbd0f7b7ce0ef731555434b386a848049d
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5097207
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#91401}

commit 3bb28f80bff6dc31e8f44939264f701798d0fc21
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Mon Nov 27 09:34:42 2023 +0100

    Reland "[heap] Switch to MainAllocator for shared space promotion"
    
    This is a reland of commit 75f956b6f3121d8870b96b515ce85e8f8c5e28b0
    
    This version of the CL fixes a data race caused by adding a page
    without synchronization. This branch was only supposed to be run
    by compaction spaces. The fix here is to simply use
    is_compaction_space() again.
    
    Original change's description:
    > [heap] Switch to MainAllocator for shared space promotion
    >
    > This CL switches the last use case of ConcurrentAllocator to
    > MainAllocator. The tricky thing about this particular use case is
    > that while the MainAllocator instance is used for GC, we are
    > actually not collecting this particular space in the case of
    > worker isolates and shared space.
    >
    > This CL solves this by introducing a new method in_gc_for_space()
    > that only returns true if this LAB is used for GC and the space
    > is currently collected as well. Some use cases of in_gc() had to be
    > switched to in_gc_for_space() for correctness.
    >
    > Alternatively one could argue that the allocator shouldn't even be
    > considered to be in a GC. However, we likely don't want shared GCs
    > to interrupt local GCs. So we would anyways need some kind of GC flag
    > for those allocators to prevent that from happening. There are
    > other smaller issues as well like that we don't have LocalHeaps for
    > GC threads that make this harder as well.
    >
    > Bug: chromium:1480975
    > Change-Id: I7c707402e928e95cb092c4c183ee69cbae285f9d
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5057489
    > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#91171}
    
    Bug: chromium:1480975
    Change-Id: I8d9bf85875406668cd7a1e4df10cd346df85b0e7
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5060292
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#91177}

commit 3f3e27d51ebca155b92cea0977a078831dc07b0a
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Mon Nov 27 07:37:09 2023 +0000

    Revert "[heap] Switch to MainAllocator for shared space promotion"
    
    This reverts commit 75f956b6f3121d8870b96b515ce85e8f8c5e28b0.
    
    Reason for revert: Seems to cause data races.
    
    Original change's description:
    > [heap] Switch to MainAllocator for shared space promotion
    >
    > This CL switches the last use case of ConcurrentAllocator to
    > MainAllocator. The tricky thing about this particular use case is
    > that while the MainAllocator instance is used for GC, we are
    > actually not collecting this particular space in the case of
    > worker isolates and shared space.
    >
    > This CL solves this by introducing a new method in_gc_for_space()
    > that only returns true if this LAB is used for GC and the space
    > is currently collected as well. Some use cases of in_gc() had to be
    > switched to in_gc_for_space() for correctness.
    >
    > Alternatively one could argue that the allocator shouldn't even be
    > considered to be in a GC. However, we likely don't want shared GCs
    > to interrupt local GCs. So we would anyways need some kind of GC flag
    > for those allocators to prevent that from happening. There are
    > other smaller issues as well like that we don't have LocalHeaps for
    > GC threads that make this harder as well.
    >
    > Bug: chromium:1480975
    > Change-Id: I7c707402e928e95cb092c4c183ee69cbae285f9d
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5057489
    > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#91171}
    
    Bug: chromium:1480975
    Change-Id: Ib30d9637f374ba833d1c4d928e5140cdcb451976
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5061229
    Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
    Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Cr-Commit-Position: refs/heads/main@{#91173}

commit bb9b37d196a7ef2ca0f9175e1e99794167a3d09e
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Thu Nov 23 14:36:54 2023 +0100

    [heap] Fix data race on Heap::global_allocation_limit_
    
    This field can be updated outside a safepoint because of
    Heap::NotifyContextDisposed(). However, at that point it might
    also be read concurrently from a background thread (to check
    whether incremental marking should be started).
    
    This CL turns this field into an atomic to fix the race.
    
    Bug: chromium:1480975
    Change-Id: I06cbfc2bd5764ce88718e0d701d066c5ef5502f6
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5057293
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#91143}

commit d15ef845947ba4ba5276038a1b1a5baa50759154
Author: Clemens Backes <clemensb@chromium.org>
Date:   Mon Sep 4 17:43:44 2023 +0200

    [wasm] Log lazily compiled code in all isolates
    
    We were missing to log lazily compiled code in other isolates that use
    the same {NativeModule}. Instead we only checked the isolate in which
    lazy compilation was triggered.
    
    This CL fixes that by calling {WasmEngine::LogCode} from {CompileLazy},
    which properly checks all isolates that use a {NativeModule}.
    As that method is pretty expensive (it takes a Mutex to protect against
    data races), we add a cheap-to-access atomic boolean to the
    {NativeModule}. The {WasmEngine} updates this whenever a new isolate
    uses a module, an isolate dies, or logging is enabled in an isolate.
    This should mitigate any performance regressions.
    
    R=thibaudm@chromium.org
    
    Bug: chromium:1407619
    Change-Id: Id21ed59ed14c6fa25c9d664c53989bb5aae09114
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4790962
    Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#89778}

commit 4564a561cb2df158b3e237f965205164a8e3ffd3
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Tue Aug 29 08:46:01 2023 +0000

    Revert "Reland "[heap] Introduce Heap::MakeNewSpaceIterable method""
    
    This reverts commit 2a76240fed2f6b0fb7e5d9bffc33da429333ef6f.
    
    Reason for revert: Causes data races
    
    Original change's description:
    > Reland "[heap] Introduce Heap::MakeNewSpaceIterable method"
    >
    > This is a reland of commit bde589f3a6fd7bba05cd2bd1381e7c8f262239a5
    >
    > This CL contains the following changes compared to the first version
    > of this CL:
    > * Use EnsureYoungSweepingCompleted() to finish minor sweeping.
    > * Avoids the PagedSpaceObjectIterator with minor ms since this
    >   class was using Heap::MakeHeapIterable() internally as well.
    >
    > Original change's description:
    > > [heap] Introduce Heap::MakeNewSpaceIterable method
    > >
    > > Add method to make the new space iterable. This is useful for a
    > > shared GC which needs the new space to be iterable.
    > >
    > > So far we simply used Heap::MakeHeapIterable for convenience for this purpose. However, this method makes the whole heap iterable which is
    > > not really necessary. But more importantly, Heap::MakeHeapIterable performs a lot of actions and e.g. creates handles in
    > > GCTracer::StopCycle. Client isolates are parked during a shared GC and therefore shouldn't create handles.
    > >
    > > Bug: chromium:1472372
    > > Change-Id: Ia15ad5153e60e90c4732338a834a099e271caeec
    > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4813236
    > > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    > > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > > Cr-Commit-Position: refs/heads/main@{#89632}
    >
    > Bug: chromium:1472372
    > Change-Id: I084bf282236c28063c5ff1796ff3525854897f2c
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4816530
    > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#89663}
    
    Bug: chromium:1472372
    Change-Id: I34427f9353b50bb483f731ebafb2e68b4cb67c63
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4821532
    Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
    Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Cr-Commit-Position: refs/heads/main@{#89670}

commit b71a94aa1891db7333dbd3b48d6b03ab6c980295
Author: Thibaud Michaud <thibaudm@chromium.org>
Date:   Fri Jul 28 11:09:34 2023 +0200

    Reland^3 "[wasm] Do not inline export wrappers for JSPI"
    
    This is a reland of commit 9b7d2a9cd9bbcec35d5008a43056bfd1e1914a81
    Also make the write to the Code::builtin_id field atomic to fix
    the last tsan failure.
    
    Original change's description:
    > Reland "Reland "[wasm] Do not inline export wrappers for JSPI""
    >
    > This is a reland of commit 9ee1ba176a52b9ba6f8a773f7b0a5f1d9c77e4af
    > Change: also load the builtin ID of the wrapper code object with
    > an atomic relaxed load to avoid another data race. (Note: the failure
    > that caused the revert is actually not caused by this CL. This is an
    > unrelated fix for v8:14220).
    >
    > Original change's description:
    > > Reland "[wasm] Do not inline export wrappers for JSPI"
    > >
    > > This is a reland of commit f43a566ce60a5e22be10ed77ebea807dcdd82a18
    > >
    > > The issue was a data race between a background compilation thread
    > > reading the wrapper_code field to check if we can inline it, and the
    > > generic wrapper tier-up trying to update the wrapper_code.
    > >
    > > It does not matter whether we read the value before or after the
    > > tier-up, so just get the field with a relaxed load.
    > >
    > > Original change's description:
    > > > [wasm] Do not inline export wrappers for JSPI
    > > >
    > > > To preserve the "JSPI behavior" of the exported function, do not inline
    > > > the optimized js-to-wasm wrapper at the call site. Keep using the
    > > > special WasmReturnPromiseOnSuspend builtin.
    > > >
    > > > R=ahaas@chromium.org
    > > >
    > > > Bug: v8:12191,v8:14200
    > > > Change-Id: I93a8b0293c0c96541c336a90317cee03410dcfd6
    > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4711685
    > > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    > > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > > > Cr-Commit-Position: refs/heads/main@{#89151}
    > >
    > > Bug: v8:12191,v8:14200
    > > Change-Id: I30459d98dd9f1942780cba344dee118011fa98bd
    > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4714608
    > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
    > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    > > Cr-Commit-Position: refs/heads/main@{#89195}
    >
    > Bug: v8:12191,v8:14200,v8:14220
    > Change-Id: Ifed60ad4b246ab8190fc511bc3b2bf182004c43a
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4720865
    > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#89230}
    
    Bug: v8:12191,v8:14200,v8:14220,v8:14227
    Change-Id: I28468f35c6e91d966a030bc40eab25d254c8e516
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4727683
    Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#89286}

commit fc299ac2bca17abeb4a185aedd57dc82d4558bf5
Author: Shu-yu Guo <syg@chromium.org>
Date:   Thu Jul 27 17:20:00 2023 +0000

    Revert "Reland "Reland "[wasm] Do not inline export wrappers for JSPI"""
    
    This reverts commit 9b7d2a9cd9bbcec35d5008a43056bfd1e1914a81.
    
    Reason for revert: More races sorry
    https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/16136/overview
    
    Original change's description:
    > Reland "Reland "[wasm] Do not inline export wrappers for JSPI""
    >
    > This is a reland of commit 9ee1ba176a52b9ba6f8a773f7b0a5f1d9c77e4af
    > Change: also load the builtin ID of the wrapper code object with
    > an atomic relaxed load to avoid another data race. (Note: the failure
    > that caused the revert is actually not caused by this CL. This is an
    > unrelated fix for v8:14220).
    >
    > Original change's description:
    > > Reland "[wasm] Do not inline export wrappers for JSPI"
    > >
    > > This is a reland of commit f43a566ce60a5e22be10ed77ebea807dcdd82a18
    > >
    > > The issue was a data race between a background compilation thread
    > > reading the wrapper_code field to check if we can inline it, and the
    > > generic wrapper tier-up trying to update the wrapper_code.
    > >
    > > It does not matter whether we read the value before or after the
    > > tier-up, so just get the field with a relaxed load.
    > >
    > > Original change's description:
    > > > [wasm] Do not inline export wrappers for JSPI
    > > >
    > > > To preserve the "JSPI behavior" of the exported function, do not inline
    > > > the optimized js-to-wasm wrapper at the call site. Keep using the
    > > > special WasmReturnPromiseOnSuspend builtin.
    > > >
    > > > R=ahaas@chromium.org
    > > >
    > > > Bug: v8:12191,v8:14200
    > > > Change-Id: I93a8b0293c0c96541c336a90317cee03410dcfd6
    > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4711685
    > > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    > > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > > > Cr-Commit-Position: refs/heads/main@{#89151}
    > >
    > > Bug: v8:12191,v8:14200
    > > Change-Id: I30459d98dd9f1942780cba344dee118011fa98bd
    > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4714608
    > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
    > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    > > Cr-Commit-Position: refs/heads/main@{#89195}
    >
    > Bug: v8:12191,v8:14200,v8:14220
    > Change-Id: Ifed60ad4b246ab8190fc511bc3b2bf182004c43a
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4720865
    > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#89230}
    
    Bug: v8:12191,v8:14200,v8:14220
    Change-Id: I7f67c0aaa2bba76ec1117a2d434dc7adc7f32fac
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4726482
    Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Auto-Submit: Shu-yu Guo <syg@chromium.org>
    Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Owners-Override: Shu-yu Guo <syg@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#89236}

commit 9b7d2a9cd9bbcec35d5008a43056bfd1e1914a81
Author: Thibaud Michaud <thibaudm@chromium.org>
Date:   Wed Jul 26 17:28:25 2023 +0200

    Reland "Reland "[wasm] Do not inline export wrappers for JSPI""
    
    This is a reland of commit 9ee1ba176a52b9ba6f8a773f7b0a5f1d9c77e4af
    Change: also load the builtin ID of the wrapper code object with
    an atomic relaxed load to avoid another data race. (Note: the failure
    that caused the revert is actually not caused by this CL. This is an
    unrelated fix for v8:14220).
    
    Original change's description:
    > Reland "[wasm] Do not inline export wrappers for JSPI"
    >
    > This is a reland of commit f43a566ce60a5e22be10ed77ebea807dcdd82a18
    >
    > The issue was a data race between a background compilation thread
    > reading the wrapper_code field to check if we can inline it, and the
    > generic wrapper tier-up trying to update the wrapper_code.
    >
    > It does not matter whether we read the value before or after the
    > tier-up, so just get the field with a relaxed load.
    >
    > Original change's description:
    > > [wasm] Do not inline export wrappers for JSPI
    > >
    > > To preserve the "JSPI behavior" of the exported function, do not inline
    > > the optimized js-to-wasm wrapper at the call site. Keep using the
    > > special WasmReturnPromiseOnSuspend builtin.
    > >
    > > R=ahaas@chromium.org
    > >
    > > Bug: v8:12191,v8:14200
    > > Change-Id: I93a8b0293c0c96541c336a90317cee03410dcfd6
    > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4711685
    > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > > Cr-Commit-Position: refs/heads/main@{#89151}
    >
    > Bug: v8:12191,v8:14200
    > Change-Id: I30459d98dd9f1942780cba344dee118011fa98bd
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4714608
    > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
    > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#89195}
    
    Bug: v8:12191,v8:14200,v8:14220
    Change-Id: Ifed60ad4b246ab8190fc511bc3b2bf182004c43a
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4720865
    Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    Reviewed-by: Andreas Haas <ahaas@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#89230}

commit 35eaaaf41d1e18c91ea36574e96236cd4c1cd30e
Author: Nikolaos Papaspyrou <nikolaos@chromium.org>
Date:   Wed Jul 26 14:49:55 2023 +0200

    [heap] Remove DCHECK from MemoryAllocator::IsOutsideAllocatedSpace
    
    The DCHECK in MemoryAllocator::IsOutsideAllocatedSpace that was
    introduced in https://crrev.com/c/4719165 is causing a data race
    between concurrent marking and page allocation. This CL removes it.
    It will be added again to the call site of this method in the CSS
    visitor, in a subsequent CL.
    
    Change-Id: Ia66596d095d61bccf1c6abcab1260c394d5304a2
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4720547
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#89212}

commit 9776f53d8303f474632046ab373b0085aaa913d6
Author: Leszek Swirski <leszeks@chromium.org>
Date:   Wed Jul 26 09:46:59 2023 +0000

    Revert "Reland "[wasm] Do not inline export wrappers for JSPI""
    
    This reverts commit 9ee1ba176a52b9ba6f8a773f7b0a5f1d9c77e4af.
    
    Reason for revert: GC Stress: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/29112/overview
    
    
    Original change's description:
    > Reland "[wasm] Do not inline export wrappers for JSPI"
    >
    > This is a reland of commit f43a566ce60a5e22be10ed77ebea807dcdd82a18
    >
    > The issue was a data race between a background compilation thread
    > reading the wrapper_code field to check if we can inline it, and the
    > generic wrapper tier-up trying to update the wrapper_code.
    >
    > It does not matter whether we read the value before or after the
    > tier-up, so just get the field with a relaxed load.
    >
    > Original change's description:
    > > [wasm] Do not inline export wrappers for JSPI
    > >
    > > To preserve the "JSPI behavior" of the exported function, do not inline
    > > the optimized js-to-wasm wrapper at the call site. Keep using the
    > > special WasmReturnPromiseOnSuspend builtin.
    > >
    > > R=ahaas@chromium.org
    > >
    > > Bug: v8:12191,v8:14200
    > > Change-Id: I93a8b0293c0c96541c336a90317cee03410dcfd6
    > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4711685
    > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > > Cr-Commit-Position: refs/heads/main@{#89151}
    >
    > Bug: v8:12191,v8:14200
    > Change-Id: I30459d98dd9f1942780cba344dee118011fa98bd
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4714608
    > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
    > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#89195}
    
    Bug: v8:12191,v8:14200
    Change-Id: I30c3323375e9c990615ea680e165ee5857dd876f
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4717492
    Auto-Submit: Leszek Swirski <leszeks@chromium.org>
    Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Owners-Override: Leszek Swirski <leszeks@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#89197}

commit 9ee1ba176a52b9ba6f8a773f7b0a5f1d9c77e4af
Author: Thibaud Michaud <thibaudm@chromium.org>
Date:   Tue Jul 25 14:02:33 2023 +0200

    Reland "[wasm] Do not inline export wrappers for JSPI"
    
    This is a reland of commit f43a566ce60a5e22be10ed77ebea807dcdd82a18
    
    The issue was a data race between a background compilation thread
    reading the wrapper_code field to check if we can inline it, and the
    generic wrapper tier-up trying to update the wrapper_code.
    
    It does not matter whether we read the value before or after the
    tier-up, so just get the field with a relaxed load.
    
    Original change's description:
    > [wasm] Do not inline export wrappers for JSPI
    >
    > To preserve the "JSPI behavior" of the exported function, do not inline
    > the optimized js-to-wasm wrapper at the call site. Keep using the
    > special WasmReturnPromiseOnSuspend builtin.
    >
    > R=ahaas@chromium.org
    >
    > Bug: v8:12191,v8:14200
    > Change-Id: I93a8b0293c0c96541c336a90317cee03410dcfd6
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4711685
    > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#89151}
    
    Bug: v8:12191,v8:14200
    Change-Id: I30459d98dd9f1942780cba344dee118011fa98bd
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4714608
    Reviewed-by: Andreas Haas <ahaas@chromium.org>
    Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
    Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#89195}

commit c53a7dff012c1869fb7e410bb7250c3901c276bb
Author: Omer Katz <omerkatz@chromium.org>
Date:   Mon Jul 10 23:06:49 2023 +0200

    [heap] Fix bug in untyped shared remembered set handling
    
    crrev.com/c/4675298 fixed a data race in
    CheckOldToNewSlotForSharedUntyped but accidentally also passed a slot
    offset instead of a slot address when inserting to the OLD_TO_SHARED
    remembered set.
    This CL resotres the previous behavior.
    
    Bug: v8:13012
    Change-Id: I0bdebd196a5b515ab2929a0ae87359f071b8390b
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4670262
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Omer Katz <omerkatz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#88803}

commit 35b8bd30a6f3fe7f95d6783aa017067401e0290c
Author: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com>
Date:   Mon May 8 16:23:20 2023 -0700

    Check for background deserialization in CollectSourcePositionsForAllBytecodeArrays
    
    There is a data race caused by the CPUProfiler trying to access the
    DebugInfo of a SharedFunctionInfo that is being deserialized in another
    thread.
    
    This CL adds a mitigation by checking if the `script_or_debug_info` of
    the SFI is set to `unititalized_deserialization_value`.
    
    
    Bug: v8:13225
    Change-Id: Ife3143183686b5a9fd7390d9ea65cbde2754a3ed
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4513482
    Commit-Queue: Victor Gomes <victorgomes@chromium.org>
    Reviewed-by: Victor Gomes <victorgomes@chromium.org>
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#87762}

commit f8b9421f0da1382227728cb220b18cf44e9c60c4
Author: Omer Katz <omerkatz@chromium.org>
Date:   Tue Mar 14 15:48:25 2023 +0100

    [heap] Fix race in ephemeron remembered set
    
    MinorMC doesn't currently use the dedicated ephemeron remembered set.
    However, there was one path in full GC that was accidentally still using
    it (only when evacuation had to be aborted).
    As a result the ephemeron key could be found in both the OLD_TO_NEW
    remembered set and the dedicated ephemeron remembered set. This leads to
    a data race during evacuation when 2 threads are both trying to update
    the key.
    
    Drive-by: drop unused MarkCompactCollector::RecordLiveSlotsOnPage.
    
    Bug: v8:13818
    Change-Id: I1ba180ef949b7db2ff2abe4f1096f94cf7c93d2b
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4338012
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Omer Katz <omerkatz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#86420}

commit 58debc3b8ffd4a61790e7e50576296c11f3c7fc1
Author: Omer Katz <omerkatz@chromium.org>
Date:   Tue Mar 14 13:48:38 2023 +0100

    [heap] Fix tsan race in sweeper
    
    Making read/writes to promoted_page_iteration_in_progress_ relaxed means
    tsan doesn't see them in terms of synchronization, causing it report
    data races in subsequent code.
    
    Bug: v8:13817
    Change-Id: Ie0f74295e31e29feab3b010b6fc974346ccd3f4b
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4337916
    Commit-Queue: Omer Katz <omerkatz@chromium.org>
    Auto-Submit: Omer Katz <omerkatz@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#86411}

commit dc7926bebd49d8749074c414dcf08a846bae0007
Author: Manos Koukoutos <manoskouk@chromium.org>
Date:   Tue Feb 21 13:58:39 2023 +0100

    Reland "[wasm] Do not store element segment entries in WasmModule"
    
    This is a reland of commit 480a491e79337163be10655ce243587b14bcefb2
    
    Change compared to original:
    Reimplement constant expression decoding and generation of a
    {Handle<Object>} in module-instantiate.cc. We fix two issues this way:
    - We fix a data race that was caused by module instantiation setting
      the {declared} field of functions in a {WasmModule}.
    - We remove a redundant decoding pass of the constant expression.
    
    Original change's description:
    > [wasm] Do not store element segment entries in WasmModule
    >
    > Instead, decode them from the wire bytes as needed. This is to save
    > some space, in anticipation of storing computed element segments in the instance object (for wasm-gc, see linked CL).
    > Drive-by: this breaks some cctests, so we move them to mjsunit.
    >
    > Bug: v8:7748
    > Change-Id: I71019f5624a33dd18f07b05107555a3fac788a8c
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4255645
    > Reviewed-by: Clemens Backes <clemensb@chromium.org>
    > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#85912}
    
    Bug: v8:7748
    Change-Id: I58dcf6cdb5e71cae983e613cb17b665479fc5c63
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4269410
    Reviewed-by: Clemens Backes <clemensb@chromium.org>
    Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#85956}

commit 23e7e5ff07a283df93eb707c0676d14e3a290151
Author: Tobias Tebbi <tebbi@chromium.org>
Date:   Fri Feb 17 10:14:37 2023 +0100

    [compiler] fix concurrent compilation race on accessing JSFunction::code
    
    The race that we fix here has basically the following structure:
    
    Main thread:
      1. Create and initialize Code object and InstructionStream objects.
      2. Store-release Code object to JSFunction::code
      3. Copy JSFunction::code from one JSFunction to another one.
    
    Background compile thread:
      1. Load-acquire JSFunction::code from the second JSFunction.
      2. Access the Code object and then the InstructionStream object.
    
    Tsan classified this as a data race, probably also because it could
    not see step (3.) on the main thread, as it is in generated code.
    
    This could be fixed by adding a release-barrier after initialization
    or by using release-stores whenever copying the `Code` pointer.
    However, it is simpler to fix it by using `TryMakeRef()`, which
    ensures that the `Code` object was either fully initialized before
    concurrent compilation started or we won't access it at all.
    
    Drive-by cleanup: Remove incomplete release-store semantic when writing
    `JSFunction::code`, which was added in https://chromium-review.googlesource.com/c/v8/v8/+/2676633
    
    Bug: v8:13705
    
    Change-Id: Ia38ecf78003641c315c10f560801c368906c937e
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4241157
    Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
    Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
    Commit-Queue: Leszek Swirski <leszeks@chromium.org>
    Reviewed-by: Leszek Swirski <leszeks@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#85878}

commit 29d54b0408cf072d42c1018367555552aea7ce5c
Author: Omer Katz <omerkatz@chromium.org>
Date:   Mon Jan 23 10:39:45 2023 +0100

    Fix data race when writing to Profiler::overflow_
    
    This CL resolves the races in
    https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8791194392783872945/+/u/Check/LogAllTest.LogAll
    
    Bug: v8:13665
    Change-Id: Ic40fe995eb9a335cdb0477106009a4d455273cb6
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4187215
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Commit-Queue: Omer Katz <omerkatz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#85438}

commit 54d255ab23bfc00308bebbd2a720946a50186b63
Author: Omer Katz <omerkatz@chromium.org>
Date:   Thu Jan 19 19:41:37 2023 +0100

    [heap] Fix race in MarkingBarrier
    
    The data race in [1] occurs because when reaching marking-barrier-inl.h,
    value is in the shared heap while host is in the client heap.
    Generally concurrent sweeping and marking barriers should not be active
    at the same time. However, that only holds for a single heap.
    In this case, the client is in the midst of incremental marking, thus
    marking barriers are active for it, while concurrent sweeping is active
    on the shared heap/space. This results in a race between reading the
    value's mark bit and clearing the mark bit for the chunk.
    
    [1] https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8791534956079065361/+/u/Check__flakes_/regress-crbug-1394741
    
    Bug: v8:13665
    Change-Id: I1b6210b9162b78b3c3635802a1e74432f5c89757
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4181038
    Auto-Submit: Omer Katz <omerkatz@chromium.org>
    Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#85412}

commit 562b65a86e6ce0cb417577a6296c5a7958d8162b
Author: Omer Katz <omerkatz@chromium.org>
Date:   Thu Jan 19 11:56:04 2023 +0100

    [heap] Fix data races in debug builds
    
    These fixes address race observed in
    https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8792972887942555249/+/u/Benchmarks__flakes_/splay
    and
    https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8792972887942555249/+/u/Check_-_extra/regress-1146013
    
    Bug: v8:13665
    Change-Id: Ief02d57907dd1930fc5c719503fd98e42171991b
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4171638
    Auto-Submit: Omer Katz <omerkatz@chromium.org>
    Reviewed-by: Leszek Swirski <leszeks@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#85393}

commit 713cf5dfa728b21c48f711fa63379c2741c6367d
Author: Omer Katz <omerkatz@chromium.org>
Date:   Fri Jan 13 15:08:10 2023 +0100

    [heap] Fix data races with concurrent promoted page iteration
    
    V8 uses memcpy and memmove for implementing Heap::CopyRange and
    Heap::MoveRange respectively, but only when concurrent marking is off.
    When concurrent marking is on, atomic stores are used to avoid data
    races.
    Since iteration of promoted pages also iterates objects concurrently,
    memcpy and memmove should be avoided while it is active as well.
    
    A dedicated bailout for promoted page iteration is added rather than
    checking when sweeping is active. Sweeping will likely be active
    until the next GC, which means relying on it here would prevent us
    from ever using memcpy and memmove.
    
    Bug: chromium:1407041
    Change-Id: Idde80b456df843f91ef7ef05c0694c5930711ae4
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4165084
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Omer Katz <omerkatz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#85318}

commit f0254afaab04039d7430f8e6c18671144dd65643
Author: Samuel Groß <saelo@chromium.org>
Date:   Wed Jan 4 13:13:12 2023 +0100

    [sandbox] Initialize EPT evacuation entries atomically
    
    Currently, evacuation entries are initialized non-atomically as they
    will only be accessed during sweeping. However, it can happen that
    another thread attempts (but fails) to allocate the same table entry,
    causing a memory read from the same entry. If that happens, TSan will
    complain about a data race. Using an atomic store avoids this.
    
    Bug: chromium:1370743
    Change-Id: Idaa5548494d4b1660ee5a798966dd09bf4b3d55c
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135880
    Commit-Queue: Samuel Groß <saelo@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#85091}

commit 825915a75cf75793394d7eea77d9d74a919bc8e0
Author: Omer Katz <omerkatz@chromium.org>
Date:   Wed Dec 7 23:40:28 2022 +0100

    [heap] Replace ZapCode in Sweeper with an atomic variant
    
    Resolve a data race between concurrent sweeping and writing fillers by
    the main thread.
    
    Bug: v8:13554, v8:12612
    Change-Id: I00bbceca92b4729b2d2bb32be0916a981cfde3e6
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4084762
    Auto-Submit: Omer Katz <omerkatz@chromium.org>
    Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#84747}

commit 60d9dd356358135d039b3ac942bb9bbd7f5663da
Author: Andreas Haas <ahaas@chromium.org>
Date:   Mon Dec 5 14:13:52 2022 +0100

    [d8] Make the profileEnd callback isolate-specific
    
    The OnProfileEndListener callback has to be reset before the isolate
    dies to avoid a use-after-free when the Global which holds the callback
    gets released.
    
    Drive-by change: make the OnProfileEndListener callback
    isolate-specific. At the moment a `profileEnd` call in IsolateA could
    trigger the OnProfileEndListener callback of IsolateB, which could
    cause all kinds of data races (the callback would access the isolate,
    but the isolate is not supposed to get accessed by multiple threads
    concurrently. With this CL there is one callback per isolate.
    
    R=clemensb@chromium.org
    
    Bug: chromium:1395237
    Change-Id: Ifaa5b883a231f5519a3bfeb6187fb7d8faa02b02
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076465
    Commit-Queue: Andreas Haas <ahaas@chromium.org>
    Reviewed-by: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#84646}

commit d07765501062f492321f4db5fbf0987fb4571c11
Author: Jakob Linke <jgruber@chromium.org>
Date:   Wed Oct 5 14:04:15 2022 +0200

    [turbofan] Tentatively fix a data race in GetOwnConstantElementFromHeap
    
    Non-atomic accesses to the HeapNumber contents of a JSArray::length
    field are invalid since neither HeapNumber construction nor accesses
    are written with thread-safety in mind. This case should be rare enough (vs. Smi lengths) that we can simply skip the optimization.
    
    Bug: chromium:1371108
    Change-Id: I7915c7eb234deebe2583a094f567c703099de2ee
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3932069
    Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
    Auto-Submit: Jakob Linke <jgruber@chromium.org>
    Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#83539}

commit d32b5ab97c6df406a678402ae4f259e55491c000
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Wed Sep 28 16:30:34 2022 +0200

    [heap] Fix data race when setting COMPACTION_WAS_ABORTED page flag
    
    When evacuation gets aborted due to OOM we used to set the
    COMPACTION_WAS_ABORTED page flag immediately. However other evacuation
    threads might check the page flags of that exact page concurrently
    while recording slots in migrated objects.
    
    We can delay setting the COMPACTION_WAS_ABORTED page flags until
    processing aborted evacuation candidates. At that point there are
    no more concurrent evacuation threads running anymore.
    
    In order to not break output of --trace-evacuation we also need a
    return value for RawEvacuatePage.
    
    Bug: v8:13336
    Change-Id: I29a76af918ee4f2016ab6d7c26c2688ff6a14aae
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925974
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#83479}

commit bae99d5b58b08144b8d5656a44fa4b4ed43e3596
Author: Anton Bikineev <bikineev@chromium.org>
Date:   Mon Aug 29 14:29:22 2022 +0200

    cppgc: Fix data race in DCHECK between markers
    
    Read of size 2 at 0x7eef001a3666 by main thread (mutexes: write M0):
     0: LoadEncoded
     1: IsMarked<(cppgc::internal::AccessMode)0>
     2: operator()
     3: DrainWorklistWithPredicate
     4: DrainWorklistWithBytesAndTimeDeadline
    
    Previous atomic write of size 2 at 0x7eef001a3666 by thread T8:
    
     0: __cxx_atomic_compare_exchange_strong<unsigned short>
     1: compare_exchange_strong
     2: TryMarkAtomic
     3: MarkNoPush
    
    Change-Id: I0708516382ea860c877ff76ee02216f6f27c9d04
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3858239
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Auto-Submit: Anton Bikineev <bikineev@chromium.org>
    Commit-Queue: Anton Bikineev <bikineev@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#82776}

commit ae44450b495073e517022ab50df6043fc1cc5dd1
Author: Leon Bettscheider <bettscheider@google.com>
Date:   Thu Aug 25 20:30:23 2022 +0200

    [heap] Fix data race in YoungGenerationMarkingVisitorBase
    
    This CL fixes a data race that was found using TSAN.
    
    Bug: v8:13012
    Change-Id: Ic29620edce116effea097a9f1d58532ba93b2224
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3857424
    Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Leon Bettscheider <bettscheider@google.com>
    Cr-Commit-Position: refs/heads/main@{#82738}

commit e93a09c212fa7937b8f1c2e976b24883e5385034
Author: Leszek Swirski <leszeks@chromium.org>
Date:   Mon Jul 25 15:15:25 2022 +0000

    Revert "Reland "cppgc: Enable pointer compression by default on Desktop""
    
    This reverts commit c3f18ae6ab86f7d1dd5f4a871b8cd123cc5ce915.
    
    Reason for revert: Speculative revert for https://luci-milo.appspot.com/ui/inv/build-8807661142690641489/test-results?q=conformance%2Fogles%2FGL%2FgreaterThanEqual%2FgreaterThanEqual_001_to_008.html
    
    Original change's description:
    > Reland "cppgc: Enable pointer compression by default on Desktop"
    >
    > - The data race on atomic memcpying/memsetting was fixed;
    > - All the known alignment issues in Blink were fixed;
    > - Several perf optimizations were applied.
    >
    > Original change's description:
    > > cppgc: Enable pointer compression by default on Desktop
    > >
    > > The CL enables pointer compression in Oilpan.
    > >
    > > For sherrifs: the CL may cause some slight perf regressions (likely
    > > blink_perf.*), due to slightly higher cost of compression and
    > > decomrpession.
    > >
    > > Speedometer2 is not expected to regress, as was checked locally. Such a
    > > slight performance degradation is compensated by memory savings that are
    > > expected to be around 10-20% of Oilpan committed size (~2.5-5% of Renderer
    > > PMF).
    >
    > Bug: chromium:1325007
    > Change-Id: I5fa9a06cb1fa5141f4e2b22e710007e2404a176b
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762567
    > Auto-Submit: Anton Bikineev <bikineev@chromium.org>
    > Commit-Queue: Anton Bikineev <bikineev@chromium.org>
    > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#81914}
    
    Bug: chromium:1325007
    Change-Id: I15baa011500a2156871277c644a004b9cacfd5f4
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3783991
    Owners-Override: Leszek Swirski <leszeks@chromium.org>
    Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Auto-Submit: Leszek Swirski <leszeks@chromium.org>
    Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Cr-Commit-Position: refs/heads/main@{#81930}

commit c3f18ae6ab86f7d1dd5f4a871b8cd123cc5ce915
Author: Anton Bikineev <bikineev@chromium.org>
Date:   Thu Jul 14 11:47:42 2022 +0200

    Reland "cppgc: Enable pointer compression by default on Desktop"
    
    - The data race on atomic memcpying/memsetting was fixed;
    - All the known alignment issues in Blink were fixed;
    - Several perf optimizations were applied.
    
    Original change's description:
    > cppgc: Enable pointer compression by default on Desktop
    >
    > The CL enables pointer compression in Oilpan.
    >
    > For sherrifs: the CL may cause some slight perf regressions (likely
    > blink_perf.*), due to slightly higher cost of compression and
    > decomrpession.
    >
    > Speedometer2 is not expected to regress, as was checked locally. Such a
    > slight performance degradation is compensated by memory savings that are
    > expected to be around 10-20% of Oilpan committed size (~2.5-5% of Renderer
    > PMF).
    
    Bug: chromium:1325007
    Change-Id: I5fa9a06cb1fa5141f4e2b22e710007e2404a176b
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762567
    Auto-Submit: Anton Bikineev <bikineev@chromium.org>
    Commit-Queue: Anton Bikineev <bikineev@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#81914}

commit 739acb48743e14ce77554239094269aa62da36cd
Author: Anton Bikineev <bikineev@chromium.org>
Date:   Wed Jun 15 12:38:17 2022 +0200

    cppgc: shared-heap: Fix data race around CagedHeap::large_pages_
    
    Now that the cage is shared, its metadata must be thread-safe.
    
    Bug: chromium:1336529
    Change-Id: I0650462d1faf171fc3325808ca45ebe044e91f45
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3707097
    Auto-Submit: Anton Bikineev <bikineev@chromium.org>
    Commit-Queue: Anton Bikineev <bikineev@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#81176}

commit 7d34f8819f3021df5aec7d23cfcd85df7b3c2c88
Author: Clemens Backes <clemensb@chromium.org>
Date:   Wed Jun 8 18:17:03 2022 +0200

    Reland "[heap] Avoid dynamic updates of FLAG_gc_interval"
    
    This is a reland of commit abcb6bb8b4ea890b20fe73096ad28c7d608da796.
    The data race is fixed by using atomic operations.
    
    Original change's description:
    > [heap] Avoid dynamic updates of FLAG_gc_interval
    >
    > Flags will be protected from updates after V8 initialization (in the
    > future). This CL avoids any updates of the --gc-interval flag during
    > runtime, and instead updates a static field on the HeapAllocator
    > directly.
    >
    > R=mlippautz@chromium.org
    >
    > Bug: v8:12887
    > Change-Id: I17a495cae50a46d59a8159c6ece1558d4d61b949
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687691
    > Commit-Queue: Clemens Backes <clemensb@chromium.org>
    > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#80998}
    
    Bug: v8:12887
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
    Change-Id: Ib5b537500413a627d9b2509354d20906e0474d8e
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695380
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#81008}

commit cd6afec260097deded534e4a7b611251f6976a3a
Author: Gabriel Charette <gab@chromium.org>
Date:   Thu Jun 2 15:01:29 2022 +0000

    [v8] Fix data race in TRACE_EVENT macros in cppgc
    
    Mirrors a Chromium change @
    https://chromium-review.googlesource.com/c/chromium/src/+/3680123
    and a v8 change @
    https://chromium-review.googlesource.com/c/v8/v8/+/3687370/
    
    Bug: chromium:1330114
    Change-Id: I61b1e34d54a496dda25936efbcd339fa35e64fb1
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3686476
    Commit-Queue: Hannes Payer <hpayer@chromium.org>
    Reviewed-by: Hannes Payer <hpayer@chromium.org>
    Auto-Submit: Gabriel Charette <gab@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#80964}

commit 1abf6972a4606e1914eab9b18121bb4e6791abd3
Author: Gabriel Charette <gab@chromium.org>
Date:   Thu Jun 2 14:58:39 2022 +0000

    [v8] Fix data race in TRACE_EVENT macros.
    
    Mirrors a Chromium change @
    https://chromium-review.googlesource.com/c/chromium/src/+/3680123
    
    Bug: chromium:1330114
    Change-Id: I6fdfd93264e669965245f5ba696fb5b605e417fe
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687370
    Auto-Submit: Gabriel Charette <gab@chromium.org>
    Reviewed-by: Hannes Payer <hpayer@chromium.org>
    Commit-Queue: Hannes Payer <hpayer@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#80963}

commit cd04f804ae3b9be51076cc12de161ee7591d7201
Author: Michael Lippautz <mlippautz@chromium.org>
Date:   Tue May 10 15:28:17 2022 +0200

    [handles] Fix benign data race
    
    Upon destroying a v8::TracedReference while concurrent marking is
    running, we merely reset the object pointer but do not get rid of the
    global handle.
    
    We were also restting the parameter which would read the internal
    state for a DCHECK. Remove this clearing as the parameter field is not
    used for v8::TracedReference.
    
    Bug: chromium:1324074
    Change-Id: Ic21bad78deba0925e12c3fc1215b087d0ef5dd7a
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3637796
    Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#80459}

commit 9e3f20b2255f6cebff8ed4ee30fe8415fcd2f4fa
Author: jameslahm <wangao.james@bytedance.com>
Date:   Mon May 9 19:23:59 2022 +0800

    [test] Move cctest/test-log to unittests/logging/log-unittest
    
    This is a reland of https://chromium-review.googlesource.com/c/v8/v8/+/3607389.
    The previous revert is https://chromium-review.googlesource.com/c/v8/v8/+/3610448.
    Reason for revert: https://crbug.com/v8/12838.
    
    The original CL has merge conflicts and cannot be relanded,
    so this CL is newly opened.
    
    This CL moves cctest/test-log to unittests/logging/log-unittest
    , fixes the flaky tests in https://bugs.chromium.org/p/v8/issues/detail?id=12838 and updates the unittests status for log-unittest.
    
    
    Flaky Tests:
    - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/7287/overview
      - flaky LogTest.Issue539892 is caused by in stress-incremental-marking
        mode, Heap::MarkCompact will trigger CodeMovingGCEvent in https://source.chromium.org/chromium/chromium/src/+/main:v8/src/heap/heap.cc;l=2586;drc=52f06e6b43ff95eccf79e0a5df8d4d83c029130a for
        FakeCodeEventLogger which was already destructed
        when Heap::PerformGarbageCollection task was handled in
        DefaultPlatform::PumpMessageLoop. This should be fixed by removing
        FakeCodeEventLogger in LogTest.Issue539892.
    
      - flaky LogTest.LogAccessorCallbacks is caused by the data race in
        Sampler::DoSample. This should be fixed in https://chromium-
        review.googlesource.com/c/v8/v8/+/3616429.
    
    -https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN/41327/overview
      - flaky LogTest.ExternalLogEventListenerWithInterpretedFramesNativeStack
        is caused by the data race of i::FLAG_* which were written again after
        setting up the isolate. This should be fixed by only writting
        i::FLAG_* before setting up the Isolate.
    
    - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64/47277/overview
      - flaky LogTest.BuiltinsNotLoggedAsLazyCompile is caused by the data
        race in Sampler::DoSample. This should be fixed in https://chromium-
        review.googlesource.com/c/v8/v8/+/3616429.
    
    Bug: v8:12781
    Change-Id: I3f736d4ffb3b8f147006bebe92285684b0c3952a
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616424
    Reviewed-by: Leszek Swirski <leszeks@chromium.org>
    Commit-Queue: 王澳 <wangao.james@bytedance.com>
    Cr-Commit-Position: refs/heads/main@{#80423}

commit 4fb91a0f2bc916e76a1f9dfc7bae743d25d8c329
Author: jameslahm <wangao.james@bytedance.com>
Date:   Wed May 4 16:15:53 2022 +0800

    [logging] Fix tsan errro between Profiler::Insert and
    
    ... Profiler::Remove.
    
    In Profiler::Insert and Profiler::Remove, TSAN cannot
    figure out that when head_ and tail_ equals, Profiler::Insert
    will always execute before Profiler::Remove, and tsan
    will report data race between buffer_[head] write and
    buffer_[base::Relaxed_Load(&tail_)]. This CL changes the
    tail_ atomic load and store memory order to gurantee that
    buffer_ read and write always after and before tail_ load
    and store, which gives tsan more constraint.
    
    Bug: v8:12838
    Change-Id: I50296ffa4606b288e9ad9edc15d42f21ca1c7d2a
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3626454
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Commit-Queue: 王澳 <wangao.james@bytedance.com>
    Cr-Commit-Position: refs/heads/main@{#80421}

commit 6e586b48906cc056057fb00c4590af3b8bf23ded
Author: jameslahm <wangao.james@bytedance.com>
Date:   Mon May 2 21:54:20 2022 +0800

    [sampler] Fix data race in Sampler::DoSample
    
    In Sampler::DoSample, we only guard SignalHandler::Installed before
    and Sampler::Stop may happen at the same time, which may cause SIGPROF
    signal handler was already restored before SIGPROF was emit and trigger
    profiling timer expired. This CL changes Sampler::DoSample to use
    SignalHandler::mutex() to guard the entire function and also change
    the mutex to recursive mutex.
    
    Bug: v8:12838
    Change-Id: I5195742ecdbade342986755233840d7be5d83c62
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616429
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Commit-Queue: 王澳 <wangao.james@bytedance.com>
    Cr-Commit-Position: refs/heads/main@{#80308}

commit f2d4a23db19828dff8b344005ec027f8a04a8aac
Author: Michael Lippautz <mlippautz@chromium.org>
Date:   Thu Feb 10 18:25:44 2022 +0100

    heap: Fix TSAN race in AllocationTrackerForDebugging
    
    The previous CLs stealth-fixed an issue where we wouldn't receive
    MoveEvent's even if FLAG_fuzzer_gc_analysis was true.
    
    The fix uncovered a data race which is fixed here.
    
    Bug: v8:12615
    Change-Id: I646dc31918d6ebe717716290375e12eac562b4b8
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3452030
    Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#79038}

commit 1c3ac2d9f4de6688059baa42dcaafece3431ff54
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Thu Feb 3 10:02:23 2022 +0100

    [heap] Fix data race when promoting objects into shared heap
    
    Each GC thread needs their own instance of ConcurrentAllocator for
    allocation. The LAB is always considered thread-local.
    
    Bug: v8:12582, v8:11708
    Change-Id: I39200202ec9fd07fa33b3ababa88e84a1a270778
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3429294
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#78917}

commit d1afc531076c9e29b306537366a56b11cf79e0e6
Author: Michael Lippautz <mlippautz@chromium.org>
Date:   Tue Feb 1 11:20:14 2022 +0100

    cppgc: Fix benign data race in MemberBase
    
    The ctors dispatch between atomic and non-atomic writes; there's no
    need for a default initializer.
    
    Bug: chromium:1292728
    Change-Id: I2b4c3341ee2d2682ba0113c8366456147ebc717e
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3429201
    Reviewed-by: Anton Bikineev <bikineev@chromium.org>
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#78884}

commit 2879f3f16c8d4db53c4258a415c88c8712445942
Author: Paolo Severini <paolosev@microsoft.com>
Date:   Sun Jan 30 17:59:34 2022 +0000

    Revert "[fastcall] Add Wasm entry for Fast API calls"
    
    This reverts commit 7f26cbd2910b034d1a11f0d220db5da04f3550b0.
    
    Reason for revert: Issue 1292333: DCHECK failure in op->IsStackSlot() || op->IsFPStackSlot() in code-generator-x64.cc
    
    Original change's description:
    > [fastcall] Add Wasm entry for Fast API calls
    >
    > Allow Wasm to generate calls directly to Fast API C functions.
    > This massively reduces the overhead of these calls (~300%).
    > Currently options parameter is not supported.
    >
    > This is a reland of
    > https://chromium-review.googlesource.com/c/v8/v8/+/3364356
    > with a fix to a data race.
    >
    > Bug: chromium:1052746
    > Change-Id: I8c1c255419496d03a94ec2b443329842469586d5
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398394
    > Reviewed-by: Maya Lekova <mslekova@chromium.org>
    > Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
    > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
    > Cr-Commit-Position: refs/heads/main@{#78714}
    
    Bug: chromium:1052746
    Change-Id: Ieb3f6f836bd604b0e4c5801f082997831eb7ac26
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3426610
    Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Reviewed-by: Maya Lekova <mslekova@chromium.org>
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
    Commit-Queue: Maya Lekova <mslekova@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#78861}

commit 7f26cbd2910b034d1a11f0d220db5da04f3550b0
Author: Paolo Severini <paolosev@microsoft.com>
Date:   Wed Jan 19 11:19:50 2022 +0100

    [fastcall] Add Wasm entry for Fast API calls
    
    Allow Wasm to generate calls directly to Fast API C functions.
    This massively reduces the overhead of these calls (~300%).
    Currently options parameter is not supported.
    
    This is a reland of
    https://chromium-review.googlesource.com/c/v8/v8/+/3364356
    with a fix to a data race.
    
    Bug: chromium:1052746
    Change-Id: I8c1c255419496d03a94ec2b443329842469586d5
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398394
    Reviewed-by: Maya Lekova <mslekova@chromium.org>
    Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Commit-Queue: Paolo Severini <paolosev@microsoft.com>
    Cr-Commit-Position: refs/heads/main@{#78714}

commit 86acc1d0845e5a042eb210d95ebac0895ada5a5d
Author: Maya Lekova <mslekova@chromium.org>
Date:   Tue Jan 18 12:43:00 2022 +0000

    Revert "[fastcall] Add Wasm entry for Fast API calls"
    
    This reverts commit bd72152e7d3364bf34eae9282467d069a6505361.
    
    Reason for revert: TSAN reports a data race, please see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/18124/overview
    
    Original change's description:
    > [fastcall] Add Wasm entry for Fast API calls
    >
    > Allow Wasm to generate calls directly to Fast API C functions.
    > This massively reduces the overhead of these calls (~300%).
    > Currently options parameter is not supported.
    >
    > This is a rebase of the work originally done by devsnek in:
    > https://chromium-review.googlesource.com/c/v8/v8/+/2718666.
    >
    > Bug: chromium:1052746
    > Change-Id: I1bb1de68b440044cc8a4e528adf9d8e0e6692a07
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364356
    > Reviewed-by: Clemens Backes <clemensb@chromium.org>
    > Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
    > Reviewed-by: Maya Lekova <mslekova@chromium.org>
    > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
    > Cr-Commit-Position: refs/heads/main@{#78664}
    
    Bug: chromium:1052746
    Change-Id: I957708cf1cff6ee8f90678ee48428f5c12f75a53
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398121
    Auto-Submit: Maya Lekova <mslekova@chromium.org>
    Owners-Override: Maya Lekova <mslekova@chromium.org>
    Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Cr-Commit-Position: refs/heads/main@{#78665}

commit 6114d098406650a52e5fc3355c2a779e4ef31559
Author: Clemens Backes <clemensb@chromium.org>
Date:   Tue Dec 7 16:35:28 2021 +0100

    [d8] Make counters fully atomic
    
    Counter updates were already atomic, but reading the counter values was
    not. This lead to data races if one isolate called `quit` while other
    isolates were still running.
    This makes counters fully atomic, and reflects that by making the fields
    {std::atomic<int>}.
    
    R=mlippautz@chromium.org
    
    Bug: v8:12481, v8:12482
    Change-Id: I6fc78ad6461b93c4b3e87bec052b0a67694539e3
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
    Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320428
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#78279}

commit 8820094a563d0d39641fe02ae82e4b114822cdb7
Author: Clemens Backes <clemensb@chromium.org>
Date:   Wed Dec 1 17:04:28 2021 +0100

    [d8] Fix data race in counter creation, update, and disposal
    
    This fixes data races when lazily creating counters (and populating the
    {counter_map_}, and when concurrently adding samples to the counters.
    It also ensures that the Wasm engine is stopped (via {V8::Dispose})
    before printing and deleting counters, as background threads might still
    try to update the counters otherwise.
    
    R=mlippautz@chromium.org
    CC=​nikolaos@chromium.org
    
    Bug: v8:12453, chromium:1275117
    Change-Id: Ie6beea6cc74eea52143d12f9921597da4a250f2a
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308710
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#78191}

commit db9c81d6880dfa94bafac91f798161f5251e9259
Author: Michael Lippautz <mlippautz@chromium.org>
Date:   Mon Nov 29 13:38:11 2021 +0100

    Reland "cppgc: Fix data race ObjectSizeTrait"
    
    This is a reland of 76f6c276748ace21b357ada700d4a0650f2c2a03
    
    Original change's description:
    > cppgc: Fix data race ObjectSizeTrait
    >
    > Fix benign race in
    >   https://clusterfuzz.com/testcase-detail/5203237072076800
    >
    > Change-Id: I558b230e4905a48342d8e7cf70d39be5a1b7fdb8
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306375
    > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    > Commit-Queue: Omer Katz <omerkatz@chromium.org>
    > Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
    > Reviewed-by: Omer Katz <omerkatz@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#78121}
    
    Change-Id: Ifa50f35591b2ae40f11a384f0fb2ff50115b2511
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306379
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Omer Katz <omerkatz@chromium.org>
    Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
    Reviewed-by: Omer Katz <omerkatz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#78124}

commit b52a7c66a2cb72e6656e95fc0d2341a5a05d5226
Author: Maya Lekova <mslekova@chromium.org>
Date:   Mon Nov 29 12:32:44 2021 +0000

    Revert "cppgc: Fix data race ObjectSizeTrait"
    
    This reverts commit 76f6c276748ace21b357ada700d4a0650f2c2a03.
    
    Reason for revert: Mac64 ASAN is unhappy, please see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20ASAN%20-%20builder/194/overview
    
    Original change's description:
    > cppgc: Fix data race ObjectSizeTrait
    >
    > Fix benign race in
    >   https://clusterfuzz.com/testcase-detail/5203237072076800
    >
    > Change-Id: I558b230e4905a48342d8e7cf70d39be5a1b7fdb8
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306375
    > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    > Commit-Queue: Omer Katz <omerkatz@chromium.org>
    > Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
    > Reviewed-by: Omer Katz <omerkatz@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#78121}
    
    Change-Id: I96c40a1e3421f59cf97efd4a844a041280989171
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306377
    Auto-Submit: Maya Lekova <mslekova@chromium.org>
    Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Owners-Override: Maya Lekova <mslekova@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#78122}

commit 76f6c276748ace21b357ada700d4a0650f2c2a03
Author: Michael Lippautz <mlippautz@chromium.org>
Date:   Mon Nov 29 12:38:32 2021 +0100

    cppgc: Fix data race ObjectSizeTrait
    
    Fix benign race in
      https://clusterfuzz.com/testcase-detail/5203237072076800
    
    Change-Id: I558b230e4905a48342d8e7cf70d39be5a1b7fdb8
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306375
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Omer Katz <omerkatz@chromium.org>
    Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
    Reviewed-by: Omer Katz <omerkatz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#78121}

commit 53d9e8b19c8086f2cf30ac5adb4e311bbe39adb0
Author: Michael Lippautz <mlippautz@chromium.org>
Date:   Wed Nov 24 20:30:54 2021 +0100

    cppgc: Fix data race in DCHECK in ObjectSizeTrait
    
    The DCHECK must use atomic accessors as well.
    
    Change-Id: I94983c1e38bc9d436f1577509788fc21e3d4e374
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300143
    Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Omer Katz <omerkatz@chromium.org>
    Reviewed-by: Omer Katz <omerkatz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#78077}

commit a6da8161197577a2221f5880cde4195f4ff92626
Author: Maya Lekova <mslekova@chromium.org>
Date:   Mon Nov 22 18:10:53 2021 +0100

    Reland^2 "[fastcall] Enable float support on arm64 simulator""
    
    This is a reland of d7c3f1cd8a2450afdfe592f87c67cead3a00b88e. It fixes
    a build failure on native arm64.
    
    Original change's description:
    > Reland "[fastcall] Enable float support on arm64 simulator"
    >
    > This is a reland of b9ddcbc86f76fb393e9343162348e976ae6d3a33
    >
    > The original CL was reverted due to an MSAN issue, that is fixed by
    > moving the signature mapping onto the Isolate (instead of having
    > per-thread storage, which got invalid on multithreaded compilation).
    >
    > This CL also contains fixes for the Bazel config and for a data race
    > when obtaining the PerIsolateSimulatorData.
    >
    > Original change's description:
    > > [fastcall] Enable float support on arm64 simulator
    > >
    > > This CL adds support for handling calls to C functions with arbitrary
    > > signatures on the arm64 simulator. It adds infrastructure for
    > > encoding the signature data from CallDescriptor and FunctionInfo
    > > classes into a compact representation, stored in the simulator and
    > > called EncodedCSignature.
    > >
    > > Design doc:
    > > https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
    > >
    > > This CL is a follow up on the native support added in
    > > https://chromium-review.googlesource.com/c/v8/v8/+/3182232
    > > and is partially based on the previous attempt:
    > > https://chromium-review.googlesource.com/c/v8/v8/+/2343072
    > >
    > > Bug: chromium:1052746
    > > Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
    > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
    > > Commit-Queue: Maya Lekova <mslekova@chromium.org>
    > > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    > > Cr-Commit-Position: refs/heads/main@{#77744}
    >
    > Bug: chromium:1052746, chromium:1267854
    > Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541
    > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    > Commit-Queue: Maya Lekova <mslekova@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#78018}
    
    Bug: chromium:1052746, chromium:1267854
    Change-Id: Ib495573569a6c930b8f9e5f1fe7ff46eb57a0aa7
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295461
    Auto-Submit: Maya Lekova <mslekova@chromium.org>
    Commit-Queue: Camillo Bruni <cbruni@chromium.org>
    Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#78063}

commit 666dcfd916b2984bef04f45716bdf7668fad5c91
Author: Victor Gomes <victorgomes@chromium.org>
Date:   Tue Nov 23 16:07:03 2021 +0100

    [heap] Fix TypedSlots data race when compiled off-thread
    
    When a LocalHeap is destroyed, we update (publish) the changes
    in the TypedSlots, this need to be protected by a mutex, since
    we may read the RecordRelocSlot in a different thread.
    
    Bug: v8:12054, v8:12411, chromium:1272364
    Change-Id: Id1684dad3ed9e02c597099c440d1fbfdbd8c47ce
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297892
    Commit-Queue: Victor Gomes <victorgomes@chromium.org>
    Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#78059}

commit 226995aebfe0bce9c1de1361e7e0d1d9cacbd084
Author: Nico Hartmann <nicohartmann@chromium.org>
Date:   Mon Nov 22 14:13:12 2021 +0000

    Revert "Reland "[fastcall] Enable float support on arm64 simulator""
    
    This reverts commit d7c3f1cd8a2450afdfe592f87c67cead3a00b88e.
    
    Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Android%20Arm64%20-%20debug%20builder/22043/overview
    
    Original change's description:
    > Reland "[fastcall] Enable float support on arm64 simulator"
    >
    > This is a reland of b9ddcbc86f76fb393e9343162348e976ae6d3a33
    >
    > The original CL was reverted due to an MSAN issue, that is fixed by
    > moving the signature mapping onto the Isolate (instead of having
    > per-thread storage, which got invalid on multithreaded compilation).
    >
    > This CL also contains fixes for the Bazel config and for a data race
    > when obtaining the PerIsolateSimulatorData.
    >
    > Original change's description:
    > > [fastcall] Enable float support on arm64 simulator
    > >
    > > This CL adds support for handling calls to C functions with arbitrary
    > > signatures on the arm64 simulator. It adds infrastructure for
    > > encoding the signature data from CallDescriptor and FunctionInfo
    > > classes into a compact representation, stored in the simulator and
    > > called EncodedCSignature.
    > >
    > > Design doc:
    > > https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
    > >
    > > This CL is a follow up on the native support added in
    > > https://chromium-review.googlesource.com/c/v8/v8/+/3182232
    > > and is partially based on the previous attempt:
    > > https://chromium-review.googlesource.com/c/v8/v8/+/2343072
    > >
    > > Bug: chromium:1052746
    > > Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
    > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
    > > Commit-Queue: Maya Lekova <mslekova@chromium.org>
    > > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    > > Cr-Commit-Position: refs/heads/main@{#77744}
    >
    > Bug: chromium:1052746, chromium:1267854
    > Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541
    > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    > Commit-Queue: Maya Lekova <mslekova@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#78018}
    
    Bug: chromium:1052746, chromium:1267854
    Change-Id: Ia8f10d085d13990b331f306957f95ecf3e003cfd
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295453
    Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
    Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
    Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#78019}

commit d7c3f1cd8a2450afdfe592f87c67cead3a00b88e
Author: Maya Lekova <mslekova@chromium.org>
Date:   Fri Nov 19 11:30:04 2021 +0100

    Reland "[fastcall] Enable float support on arm64 simulator"
    
    This is a reland of b9ddcbc86f76fb393e9343162348e976ae6d3a33
    
    The original CL was reverted due to an MSAN issue, that is fixed by
    moving the signature mapping onto the Isolate (instead of having
    per-thread storage, which got invalid on multithreaded compilation).
    
    This CL also contains fixes for the Bazel config and for a data race
    when obtaining the PerIsolateSimulatorData.
    
    Original change's description:
    > [fastcall] Enable float support on arm64 simulator
    >
    > This CL adds support for handling calls to C functions with arbitrary
    > signatures on the arm64 simulator. It adds infrastructure for
    > encoding the signature data from CallDescriptor and FunctionInfo
    > classes into a compact representation, stored in the simulator and
    > called EncodedCSignature.
    >
    > Design doc:
    > https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
    >
    > This CL is a follow up on the native support added in
    > https://chromium-review.googlesource.com/c/v8/v8/+/3182232
    > and is partially based on the previous attempt:
    > https://chromium-review.googlesource.com/c/v8/v8/+/2343072
    >
    > Bug: chromium:1052746
    > Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
    > Commit-Queue: Maya Lekova <mslekova@chromium.org>
    > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#77744}
    
    Bug: chromium:1052746, chromium:1267854
    Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541
    Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Commit-Queue: Maya Lekova <mslekova@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#78018}

commit 9e9c61b6f21bce8a0b982e4057537057662fca5c
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Fri Nov 12 15:34:06 2021 +0100

    [objects] Use atomic for JSGlobalObject::native_context_unchecked
    
    Speculative fix for a data race involving memory measurement. For memory
    measurement we use JSGlobalObject::native_context_unchecked in
    NativeContextInferrer::InferForJSObject when trying to infer the
    NativeContext for a JS object from a concurrent marking thread. This
    load can race e.g. with the context deserializer running on the main
    thread. Fix this race by making the load relaxed atomic.
    
    Bug: chromium:1269681
    Change-Id: Id04a92572d7d722594b2f8465e579b7231e54e29
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277885
    Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#77870}

commit aee050bd40d5054275dffee8d8d9e1108e7dd9a4
Author: Victor Gomes <victorgomes@chromium.org>
Date:   Tue Nov 2 14:28:31 2021 +0100

    [heap] Fix data race in large code space
    
    Data race access to chunk_map_. The main thread can read the map
    while the background thread (concurrent SP compiler) adds a new page
    to the map.
    
    Bug: v8:12054
    Change-Id: Ie7c596f3d3aeb4dca9cc6f41ed16f39dcafc7871
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256547
    Commit-Queue: Victor Gomes <victorgomes@chromium.org>
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Auto-Submit: Victor Gomes <victorgomes@chromium.org>
    Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#77654}

commit af1ccea736729ccd3e99b31cd303020d861f510b
Author: Victor Gomes <victorgomes@chromium.org>
Date:   Thu Oct 21 11:11:28 2021 +0200

    [heap] Support registering code on the background thread
    
    We use a mutex to avoid data race when reading/writing to the
    code object registry.
    
    Functions called only by the sweeper happens during safepoints and
    do not need to be protected by the mutex.
    
    Bug: v8:12054
    Change-Id: Ie85bf0422622eee7f2836ecae132397a6aa4ed59
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234721
    Commit-Queue: Victor Gomes <victorgomes@chromium.org>
    Auto-Submit: Victor Gomes <victorgomes@chromium.org>
    Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#77490}

commit defedd0c26af74635a0dd8ebab7f369e5026ee4b
Author: Georg Neis <neis@chromium.org>
Date:   Thu Sep 16 14:47:59 2021 +0200

    [compiler] Fix data race between FindRootMap and DetachGlobal
    
    ... by adding atomic (relaxed) accessor's for a map's
    constructor_or_backpointer field, and using them in the two functions.
    
    Bug: chromium:1250216, v8:7790
    Change-Id: I3416799cca73792ff5f8963685274ad9afdc6229
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162129
    Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    Commit-Queue: Georg Neis <neis@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#76876}

commit 0d50bda4a7c9020259fb07f7f1bfc9810e18262a
Author: Michael Lippautz <mlippautz@chromium.org>
Date:   Wed Sep 15 22:50:17 2021 +0200

    cppgc: Fix data race when replacing a LAB
    
    ClusterFuzz reported a non-reproducible issue here:
      https://clusterfuzz.com/testcase-detail/4634185246244864
    
    What happens here is that a LAB is replaced that is adjacent to a live
    object that is concurrently being marked using the object start
    bitmap.
    
    Bug: chromium:1056170
    Change-Id: Iebc0db6b85262f2f544a76bac9b3d1c662e41d6a
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162603
    Reviewed-by: Omer Katz <omerkatz@chromium.org>
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#76865}

commit 760682da3efa4171a67387b01817811c35887176
Author: Michael Lippautz <mlippautz@chromium.org>
Date:   Tue Aug 31 12:50:26 2021 +0200

    cppgc: Fix CTP destruction
    
    Double-checked locking pattern for destruction was missing the acquire
    barrier for the initial load.
    
    TSAN complained with a data race where:
    T1: ClearAllUsedNodes(), clearing out the node
    T2: a. if(GetNodeSafe()) { Lock; ... }
    T2: b. operator delete
    
    Since GetNodeSafe() was a relaxed load, operator delete was allowed to
    be reordered which raced with ClearAllUsedNodes().
    
    Bug: chromium:1239081, chromium:1242795
    Change-Id: I3906555b13cc51538a1a54b7ca481a96d81fd84e
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3132264
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Reviewed-by: Omer Katz <omerkatz@chromium.org>
    Reviewed-by: Anton Bikineev <bikineev@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#76599}

commit 44f284343b9eab63427c00a7a093dd9a763d7791
Author: Michael Lippautz <mlippautz@chromium.org>
Date:   Fri Aug 20 22:34:02 2021 +0200

    cppgc: Fix benign data race in CTP destruction
    
    Consider reading the internal node pointer instead of the actual pointer
    when trying to figure out whether a node needs to be destroyed. This
    preserves the non-atomiticity of the actual pointer which highlights
    races using TSAN while fixing destruction.
    
    Bug: chromium:1239081
    Change-Id: I1d1fa29d40d86e4b156269abc90142ee71a8d8f4
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3110199
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Reviewed-by: Omer Katz <omerkatz@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#76415}

commit 69b1e0eca60ce5de3ca59e715d1b8f518023a159
Author: Igor Sheludko <ishell@chromium.org>
Date:   Tue Jul 20 19:13:55 2021 +0200

    [ext-code-space][heap] Implement custom marking of CodeObjectSlots
    
    ... which will update both the CodeObjectSlot contents and the cached
    value of the code entry point when the pointed Code object is
    evacuated.
    This is done by introducing an OLD_TO_CODE remembered set which is
    populated with the recorded slots containing pointers to Code objects.
    CodeDataContainer is the only kind of holder that can contain Code
    pointers, so having a CodeObjectSlot is enough to compute the holder
    CodeDataContainer object and update the cached code entry point there.
    
    This CL fixes the data race in the previous implementation which were
    updating the code entry point during Code object migration.
    
    Bug: v8:11880
    Change-Id: I44aa46af4bad7eb4eaa922b6876d5f2f836e0791
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035084
    Commit-Queue: Igor Sheludko <ishell@chromium.org>
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#75826}

commit 974190b4848a7efd7bde8401dbac78c8ea7cdada
Author: Clemens Backes <clemensb@chromium.org>
Date:   Fri Jul 16 12:59:10 2021 +0200

    Fix data race in TypedArray::copyWithin
    
    Just like many other operations implemented in elements.cc, copyWithin
    also needs to use relaxed atomics if operating on a shared array buffer
    to avoid races with other threads.
    Since the ranges can overlap, this CL also adds a {Relaxed_Memmove}
    function that either copies forwards (like {Relaxed_Memcpy}) or
    backwards depending on the ordering of source and destination.
    
    R=leszeks@chromium.org
    
    Bug: chromium:1221035
    Change-Id: I76b7e43810ac9b85f4ff9abbc5a0406618771c25
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3032084
    Reviewed-by: Leszek Swirski <leszeks@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#75752}

commit 6a1063c89961198a1c08ef7f85e3db0082c91362
Author: Mike Stanton <mvstanton@chromium.org>
Date:   Mon Jul 5 16:41:50 2021 +0200

    [compiler] TSAN data race on HeapNumber::value_as_bits()
    
    TurboFan reads the value in HeapNumber, and TSAN detects a data
    race between this read and sets on the main thread elsewhere.
    We mark this as relaxed atomic (meaning, correct value of the read
    is not guaranteed). The compiler uses the dependency mechanism
    to re-read the value safely on the main thread later, and aborts
    compilation if a change is detected.
    
    Bug: chromium:1224277, v8:7790
    Change-Id: I8931d8989812550c0c57b6bd27aa796f6f5e779d
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996201
    Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
    Reviewed-by: Leszek Swirski <leszeks@chromium.org>
    Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
    Reviewed-by: Andreas Haas <ahaas@chromium.org>
    Commit-Queue: Michael Stanton <mvstanton@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#75586}

commit fa58f8ef0f0141f680ccd7fe50a1feb0e68197bf
Author: Jakob Linke <jgruber@chromium.org>
Date:   Thu Jul 1 09:19:46 2021 +0200

    [compiler] Fix data race in TryGetPropertyCell
    
    Bug: v8:7790, chromium:1225521
    Change-Id: I4210ca9d3eccdc4de0b5b865bac37dc32b8e6f17
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999085
    Commit-Queue: Jakob Gruber <jgruber@chromium.org>
    Commit-Queue: Georg Neis <neis@chromium.org>
    Auto-Submit: Jakob Gruber <jgruber@chromium.org>
    Reviewed-by: Georg Neis <neis@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#75499}

commit 4d2869dc1f4ec953fe36c36ae396d4a9940c9703
Author: Mike Stanton <mvstanton@chromium.org>
Date:   Thu Jun 17 12:57:39 2021 +0200

    [compiler] Fix data race in JSObject::RawFastInobjectPropertyAtPut
    
    Mark the write of the property as relaxed atomic. The compiler thread
    is examining the value. It is fine if the value is stale or new, we
    simply need to let TSAN know we are aware of the race.
    
    BUG=v8:11896
    
    Change-Id: I42505a6e12c7eb3c1ef8d9376d7a420567646d62
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968403
    Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
    Commit-Queue: Michael Stanton <mvstanton@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#75209}

commit 52b6258645adfeae975f9c1b97d93d4b526851ed
Author: Mike Stanton <mvstanton@chromium.org>
Date:   Thu Jun 17 13:05:49 2021 +0200

    [compiler] Fix data race in PropertyArray length and hash
    
    The PropertyArray may store the hash of it's parent object. This hash
    can be installed at various points. Meanwhile, the background compiler
    thread inspects the length field.
    
    BUG=chromium:1220974
    
    Change-Id: I7b13fd4546fb48e649fcbf67dee02d7c668393f2
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967471
    Commit-Queue: Michael Stanton <mvstanton@chromium.org>
    Reviewed-by: Georg Neis <neis@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#75208}

commit da45d855ded93ba0bb75645a6aef7fda83bd5017
Author: Shu-yu Guo <syg@chromium.org>
Date:   Wed Jun 9 10:58:57 2021 -0700

    Fix data races in TypedArray fill and reverse
    
    Bug: chromium:1217573
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
    Change-Id: Ida9cabc4f46f0ad4f35e2b97f5803cc7c30fb972
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2947857
    Commit-Queue: Shu-yu Guo <syg@chromium.org>
    Reviewed-by: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#75058}

commit 47d292459347e782f0f8b7a65a058fd9e0748ec2
Author: Shu-yu Guo <syg@chromium.org>
Date:   Thu May 27 16:38:59 2021 -0700

    Fix data race in TypedArray constructor
    
    Use Relaxed_Memcpy when making a new TypedArray that copies from a
    SharedArrayBuffer.
    
    Bug: chromium:1209639
    Change-Id: Iaa1f069552f0aa42a1f423e5ee0a913b3330153c
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2923274
    Reviewed-by: Igor Sheludko <ishell@chromium.org>
    Commit-Queue: Shu-yu Guo <syg@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#74842}

commit 52cf5069e1c0f19f24235c3663fccf18ec6b70ac
Author: Clemens Backes <clemensb@chromium.org>
Date:   Thu May 6 15:00:41 2021 +0200

    Speed up a new regression test
    
    The test takes several minutes on slower bots, so speed it up a bit
    without removing the ability to hit the data race.
    
    R=ulan@chromium.org
    
    Bug: chromium:1205290, v8:11741
    Change-Id: I57e411bfa2ff2a22bef1a916b74f7684b2f0be17
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876855
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#74408}

commit 9c5623c72e847f96382c211ca296266adf10c6ea
Author: Clemens Backes <clemensb@chromium.org>
Date:   Thu May 6 12:29:20 2021 +0200

    Fix data race in array sorting
    
    For copying the SharedArrayBuffer content, we cannot use a simple
    {memcpy} because that produces data races with thread concurrently
    modifying the content. Instead, use a custom {Relaxed_Memcpy} that uses
    proper relaxed atomics. The implementation is slightly optimized to do
    word-sized loads and stores where possible. If we still get performance
    regressions, we can optimize it further in follow-up CLs.
    
    R=ulan@chromium.org
    CC=mlippautz@chromium.org
    
    Bug: v8:11704, chromium:1205290
    Change-Id: Ie34afc5c22ec5496c0fe822d55d4788031f06c54
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874652
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#74403}

commit 8c3c89b0c0713ecbb60ad6f1e27602b66aba084a
Author: Clemens Backes <clemensb@chromium.org>
Date:   Thu Apr 22 18:22:57 2021 +0200

    [wasm] Abort wrapper compilation on isolate shutdown
    
    JS-to-Wasm wrappers embed heap constants (like the undefined value), and
    those heap values are being accessed during compilation for tracing.
    This is not a data race, since those values are read-only. But if the
    isolate dies while we are compiling those wrappers, we might read from
    the heap after it has been free'd.
    
    Ideally we would not access the isolate or the heap at all during
    compilation, but delaying all tracing until the "finalization" phase is
    not feasible, and removing the heap value printing from tracing would
    significantly regress quality of this tracing.
    
    Hence this CL only fixes the actual issue: That we keep compiling
    wrappers when the isolate is already gone. It does so by introducing an
    {OperationsBarrier} per isolate that is being taken by each thread that
    executes wrapper compilation, and is used for waiting for background
    threads to finish before the isolate shuts down.
    Additionally, we actually cancel all compilation if a module dies (or
    the isolate shuts down) before it finished baseline compilation. In this
    state, the module cannot be shared between isolates yet, so it's safe to
    fully cancel all compilation. This cancellation is not strictly
    necessary, but it will reduce the time we are blocked while waiting for
    wrapper compilation to finish (because no new compilation will start).
    
    R=thibaudm@chromium.org
    CC=manoskouk@chromium.org
    
    Bug: v8:11626, chromium:1200231
    Change-Id: I5b19141d22bd0cb00ba84ffa53fb07cf001e13cc
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846881
    Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#74142}

commit 09e0ad9a7438129f50dbafeef8f4084bd1c784ee
Author: Jakob Linke <jgruber@chromium.org>
Date:   Thu Apr 15 10:13:42 2021 +0200

    [compiler] Fix more concurrency issues exposed by tsan
    
    - FLAG_turbo_inline_js_wasm_calls data race
    - Map::instance_descriptors non-atomic concurrent loads
    - Skip one more cctest incompatible with stress_concurrent_inlining
    
    Bug: v8:7790,v8:11648,v8:11651
    Change-Id: Ie4833373a1da34497f4cfe129254071d8a5772dd
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2827891
    Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
    Reviewed-by: Georg Neis <neis@chromium.org>
    Commit-Queue: Jakob Gruber <jgruber@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#73970}

commit 4b5e0509104e55c2830926d403c83ba71d6a0b00
Author: Omer Katz <omerkatz@chromium.org>
Date:   Tue Mar 23 22:51:44 2021 +0100

    cppgc: Add missing page sync to TraceTrait of mixins
    
    Every page that can be accessed concurrently during marking needs to be
    synced to avoid data races with page alloation. TraceTrait for mixins
    uses the object start bitmap of a page and thus requires a sync.
    
    Bug: chromium:10561670
    Change-Id: Ia26be973019dcd1d9f7650cc139b16369d515df6
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783023
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Omer Katz <omerkatz@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#73623}

commit 591db5d98bc69a8d08f28285a7ab28b0c094cdf4
Author: Clemens Backes <clemensb@chromium.org>
Date:   Wed Jan 27 16:48:19 2021 +0100

    [wasm] Fix data race in lazy compilation
    
    Instead of updating the detected features set directly, use the
    synchronized {OnCompilationStopped} method.
    In order to avoid this error in the future, the whole
    {detected_features()} getter is removed, as it returns a pointer which
    can only be accessed when holding the mutex anyway. Also, the refactored
    code was the only user of this dangerous method.
    
    Drive-by: Pass the WasmFeatures set by value, since it's just an
    EnumSet.
    Drive-by 2: Remove a print line from the regression test which can be
    confusing if the test is picked up again by foozzie.
    
    R=ahaas@chromium.org
    CC=zhin@chromium.org
    
    Bug: v8:11357
    Change-Id: I75b5c8f35983d2bc1fd2b61adcb2ecfc18564f39
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653226
    Reviewed-by: Zhi An Ng <zhin@chromium.org>
    Reviewed-by: Andreas Haas <ahaas@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#72375}

commit 893f32fe9ebcba22c9653645468f56bdd9ff8f71
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Tue Dec 15 21:39:04 2020 +0100

    Reland^3 [heap] Add epoch to GC tracing events
    
    This is a reland of b614cd78c30c6586f0d6440df3c85bbe660f11fc
    
    Original change's description:
    > Reland "Reland "[heap] Add epoch to GC tracing events""
    >
    > This is a reland of 3238162da7d1f98a7774426b7673de60f1fe2cbc
    >
    > No changes since the last reland.
    >
    > Original change's description:
    > > Reland "[heap] Add epoch to GC tracing events"
    > >
    > > This is a reland of be52501d5214e25567e28d92d940e4e15011f345
    > >
    > > Fix data race by not emitting the epoch for sweeper background jobs
    > > at them moment.
    > >
    > > Original change's description:
    > > > [heap] Add epoch to GC tracing events
    > > >
    > > > This CL adds the TRACE_GC_EPOCH macro, which adds the epoch as attribute
    > > > to the trace event. Use TRACE_GC_EPOCH for top-level events, nested
    > > > events can get the information from its parent.
    > > >
    > > > V8's GC needs an epoch for young and full collections, since scavenges
    > > > also occur during incremental marking. The epoch is also process-wide,
    > > > so different isolates do not reuse the same id.
    > > >
    > > > Change-Id: I8889bccce51e008374b4796445a50062bd87a45d
    > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565247
    > > > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > > > Cr-Commit-Position: refs/heads/master@{#71521}
    > >
    > > Change-Id: Ib8f4bfdc01c459955eb6db63bb6e24a8aa068f09
    > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567702
    > > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > > Cr-Commit-Position: refs/heads/master@{#71567}
    >
    > TBR=ulan@chromium.org,dinfuehr@chromium.org
    >
    > Change-Id: I09dcfabbad4ef1ad50e02a227282982cd7d87997
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571122
    > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#71609}
    
    Change-Id: I89dfa5c7658197348a39be51b75dba77bfd4a70b
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2577470
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71777}

commit fc1d6f35ef52c6b2f63c30e019d690037d2ee7e1
Author: Etienne Pierre-doray <etiennep@chromium.org>
Date:   Wed Dec 2 11:29:08 2020 -0500

    Reland "Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob.""
    
    This is a reland of 064ee3c8358195dfce7f34e4deaa3f74f0caa325
    
    Issue 1: WasmEngine UAF when CompilationState is destroyed
    asynchronously
    Fix: Include https://chromium-review.googlesource.com/c/v8/v8/+/2565508
    in this CL. Use OperationBarrier to keep WasmEngine alive.
    
    Issue 2: In gin, JobTask lifetime is not extended beyond
    JobHandle, thus making CancelAndDetach unusable.
    This is fixed in chromium here:
    https://chromium-review.googlesource.com/c/chromium/src/+/2566724
    
    Original change's description:
    > Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."
    >
    > Reason for revert: Data race:
    > https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121
    >
    > It was assume that MockPlatform runs everything on 1 thread. However,
    > MockPlatform::PostJob previously would schedule the job through
    > TestPlatform, which eventually posts concurrent tasks, thus causing
    > data race.
    > Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform
    > ensures the jobs also run sequentially.
    >
    > Additional change:
    > - CancelAndDetach is now called in ~CompilationStateImpl() to make sure
    > it's called in sequence with ScheduleCompileJobForNewUnits
    >
    > Original CL description:
    > To avoid keeping around a list of job handles, CancelAndDetach() is
    > used in CancelCompilation. Dependency on WasmEngine is handled by a
    > barrier that waits on all jobs to finish.
    >
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659
    > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
    > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > Reviewed-by: Clemens Backes <clemensb@chromium.org>
    > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
    > Cr-Original-Commit-Position: refs/heads/master@{#71074}
    > Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137
    > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
    > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#71459}
    
    TBR=ulan@chromium.org
    
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
    Change-Id: I6175092c97fea0d5f63a97af232e2d54cccea535
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569360
    Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
    Reviewed-by: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71662}

commit fb37749a83f941eac0cb7865ceb6590ee6d79dc2
Author: Sathya Gunasekaran <gsathya@chromium.org>
Date:   Fri Dec 4 11:07:46 2020 +0000

    Revert "Reland "Reland "[heap] Add epoch to GC tracing events"""
    
    This reverts commit b614cd78c30c6586f0d6440df3c85bbe660f11fc.
    
    Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64/40448/overview
    
    Original change's description:
    > Reland "Reland "[heap] Add epoch to GC tracing events""
    >
    > This is a reland of 3238162da7d1f98a7774426b7673de60f1fe2cbc
    >
    > No changes since the last reland.
    >
    > Original change's description:
    > > Reland "[heap] Add epoch to GC tracing events"
    > >
    > > This is a reland of be52501d5214e25567e28d92d940e4e15011f345
    > >
    > > Fix data race by not emitting the epoch for sweeper background jobs
    > > at them moment.
    > >
    > > Original change's description:
    > > > [heap] Add epoch to GC tracing events
    > > >
    > > > This CL adds the TRACE_GC_EPOCH macro, which adds the epoch as attribute
    > > > to the trace event. Use TRACE_GC_EPOCH for top-level events, nested
    > > > events can get the information from its parent.
    > > >
    > > > V8's GC needs an epoch for young and full collections, since scavenges
    > > > also occur during incremental marking. The epoch is also process-wide,
    > > > so different isolates do not reuse the same id.
    > > >
    > > > Change-Id: I8889bccce51e008374b4796445a50062bd87a45d
    > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565247
    > > > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > > > Cr-Commit-Position: refs/heads/master@{#71521}
    > >
    > > Change-Id: Ib8f4bfdc01c459955eb6db63bb6e24a8aa068f09
    > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567702
    > > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > > Cr-Commit-Position: refs/heads/master@{#71567}
    >
    > TBR=ulan@chromium.org,dinfuehr@chromium.org
    >
    > Change-Id: I09dcfabbad4ef1ad50e02a227282982cd7d87997
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571122
    > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#71609}
    
    TBR=ulan@chromium.org,dinfuehr@chromium.org
    
    Change-Id: I9dfd37f969ec0c5e5f278e6a82732995fd82e5d9
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2574002
    Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
    Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71610}

commit b614cd78c30c6586f0d6440df3c85bbe660f11fc
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Wed Dec 2 14:03:29 2020 +0100

    Reland "Reland "[heap] Add epoch to GC tracing events""
    
    This is a reland of 3238162da7d1f98a7774426b7673de60f1fe2cbc
    
    No changes since the last reland.
    
    Original change's description:
    > Reland "[heap] Add epoch to GC tracing events"
    >
    > This is a reland of be52501d5214e25567e28d92d940e4e15011f345
    >
    > Fix data race by not emitting the epoch for sweeper background jobs
    > at them moment.
    >
    > Original change's description:
    > > [heap] Add epoch to GC tracing events
    > >
    > > This CL adds the TRACE_GC_EPOCH macro, which adds the epoch as attribute
    > > to the trace event. Use TRACE_GC_EPOCH for top-level events, nested
    > > events can get the information from its parent.
    > >
    > > V8's GC needs an epoch for young and full collections, since scavenges
    > > also occur during incremental marking. The epoch is also process-wide,
    > > so different isolates do not reuse the same id.
    > >
    > > Change-Id: I8889bccce51e008374b4796445a50062bd87a45d
    > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565247
    > > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > > Cr-Commit-Position: refs/heads/master@{#71521}
    >
    > Change-Id: Ib8f4bfdc01c459955eb6db63bb6e24a8aa068f09
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567702
    > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#71567}
    
    TBR=ulan@chromium.org,dinfuehr@chromium.org
    
    Change-Id: I09dcfabbad4ef1ad50e02a227282982cd7d87997
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571122
    Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71609}

commit 78e9a3a7fcec2c1454f224a4a4cad5fb7039bf70
Author: Maya Lekova <mslekova@chromium.org>
Date:   Wed Dec 2 15:28:23 2020 +0000

    Revert "Reland "[heap] Add epoch to GC tracing events""
    
    This reverts commit 3238162da7d1f98a7774426b7673de60f1fe2cbc.
    
    Reason for revert: Speculative revert for https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64/40411/overview, causing SEGV_ACCERR on test/mjsunit/harmony/promise-any-overflow-2.js and other failures in minor_mc variant
    
    Original change's description:
    > Reland "[heap] Add epoch to GC tracing events"
    >
    > This is a reland of be52501d5214e25567e28d92d940e4e15011f345
    >
    > Fix data race by not emitting the epoch for sweeper background jobs
    > at them moment.
    >
    > Original change's description:
    > > [heap] Add epoch to GC tracing events
    > >
    > > This CL adds the TRACE_GC_EPOCH macro, which adds the epoch as attribute
    > > to the trace event. Use TRACE_GC_EPOCH for top-level events, nested
    > > events can get the information from its parent.
    > >
    > > V8's GC needs an epoch for young and full collections, since scavenges
    > > also occur during incremental marking. The epoch is also process-wide,
    > > so different isolates do not reuse the same id.
    > >
    > > Change-Id: I8889bccce51e008374b4796445a50062bd87a45d
    > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565247
    > > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > > Cr-Commit-Position: refs/heads/master@{#71521}
    >
    > Change-Id: Ib8f4bfdc01c459955eb6db63bb6e24a8aa068f09
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567702
    > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#71567}
    
    TBR=ulan@chromium.org,dinfuehr@chromium.org
    
    Change-Id: I29a131f798c3536d16e4b4c44c0fcb8b35dd0051
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569764
    Reviewed-by: Maya Lekova <mslekova@chromium.org>
    Commit-Queue: Maya Lekova <mslekova@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71569}

commit 3238162da7d1f98a7774426b7673de60f1fe2cbc
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Wed Dec 2 14:03:29 2020 +0100

    Reland "[heap] Add epoch to GC tracing events"
    
    This is a reland of be52501d5214e25567e28d92d940e4e15011f345
    
    Fix data race by not emitting the epoch for sweeper background jobs
    at them moment.
    
    Original change's description:
    > [heap] Add epoch to GC tracing events
    >
    > This CL adds the TRACE_GC_EPOCH macro, which adds the epoch as attribute
    > to the trace event. Use TRACE_GC_EPOCH for top-level events, nested
    > events can get the information from its parent.
    >
    > V8's GC needs an epoch for young and full collections, since scavenges
    > also occur during incremental marking. The epoch is also process-wide,
    > so different isolates do not reuse the same id.
    >
    > Change-Id: I8889bccce51e008374b4796445a50062bd87a45d
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565247
    > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#71521}
    
    Change-Id: Ib8f4bfdc01c459955eb6db63bb6e24a8aa068f09
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567702
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71567}

commit 20236145af331a1c4cae94cd43af87435c24ccb2
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Tue Dec 1 13:55:47 2020 +0100

    [test] Use EnsureFlagLocalHeapsEnabled() for enabling FLAG_local_heaps
    
    Avoid data race when enabling flag with concurrent thread that reads
    that flag as well.
    
    Bug: v8:10315
    Change-Id: I9eecc48e21b1070e8db444021264eec2784f5102
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567697
    Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71528}

commit 393782efee2feadaf3e5a5b57720f684d34ff3e4
Author: Etienne Pierre-Doray <etiennep@chromium.org>
Date:   Tue Dec 1 01:01:08 2020 +0000

    Revert "Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob.""
    
    This reverts commit 064ee3c8358195dfce7f34e4deaa3f74f0caa325.
    
    Reason for revert: Causing blink_web_tests to fail on builder "WebKit Linux MSAN"
    https://bugs.chromium.org/p/chromium/issues/detail?id=1153968
    
    Original change's description:
    > Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."
    >
    > Reason for revert: Data race:
    > https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121
    >
    > It was assume that MockPlatform runs everything on 1 thread. However,
    > MockPlatform::PostJob previously would schedule the job through
    > TestPlatform, which eventually posts concurrent tasks, thus causing
    > data race.
    > Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform
    > ensures the jobs also run sequentially.
    >
    > Additional change:
    > - CancelAndDetach is now called in ~CompilationStateImpl() to make sure
    > it's called in sequence with ScheduleCompileJobForNewUnits
    >
    > Original CL description:
    > To avoid keeping around a list of job handles, CancelAndDetach() is
    > used in CancelCompilation. Dependency on WasmEngine is handled by a
    > barrier that waits on all jobs to finish.
    >
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659
    > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
    > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > Reviewed-by: Clemens Backes <clemensb@chromium.org>
    > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
    > Cr-Original-Commit-Position: refs/heads/master@{#71074}
    > Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137
    > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
    > Reviewed-by: Andreas Haas <ahaas@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#71459}
    
    TBR=ulan@chromium.org,jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,etiennep@chromium.org
    Bug: chromium:1153968, v8:11209, v8:11210, v8:11212
    
    # Not skipping CQ checks because original CL landed > 1 day ago.
    
    Change-Id: I2c8406bea81ee7cf6c5726c2fec50fffdce09611
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566446
    Reviewed-by: Clemens Backes <clemensb@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71519}

commit 064ee3c8358195dfce7f34e4deaa3f74f0caa325
Author: Etienne Pierre-doray <etiennep@chromium.org>
Date:   Fri Nov 27 11:51:25 2020 -0500

    Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."
    
    Reason for revert: Data race:
    https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121
    
    It was assume that MockPlatform runs everything on 1 thread. However,
    MockPlatform::PostJob previously would schedule the job through
    TestPlatform, which eventually posts concurrent tasks, thus causing
    data race.
    Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform
    ensures the jobs also run sequentially.
    
    Additional change:
    - CancelAndDetach is now called in ~CompilationStateImpl() to make sure
    it's called in sequence with ScheduleCompileJobForNewUnits
    
    Original CL description:
    To avoid keeping around a list of job handles, CancelAndDetach() is
    used in CancelCompilation. Dependency on WasmEngine is handled by a
    barrier that waits on all jobs to finish.
    
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659
    Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Clemens Backes <clemensb@chromium.org>
    Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
    Cr-Original-Commit-Position: refs/heads/master@{#71074}
    Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137
    Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
    Reviewed-by: Andreas Haas <ahaas@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71459}

commit 424e7a062398c61c32ba27c1daeab63a196feb96
Author: Clemens Backes <clemensb@chromium.org>
Date:   Tue Nov 10 14:17:53 2020 +0100

    [wasm][cleanup] Avoid data race on has_priority_ field
    
    After https://crrev.com/c/2529140, the actual data race should already
    be fixed. This CL updates documentation (by moving the field to the
    fields protected by {mutex_}), and updates {SetHighPriority} to also
    take the mutex. This change is not strictly necessary, because this
    method is only called right after creating the object, so no other
    threads have access to it yet. But relying on that seems brittle, and
    moving the initialization to the constructor is a bigger refactoring
    that I don't consider worth it at the moment. The whole priority
    management will probably be refactored again soon anyway.
    
    R=ahaas@chromium.org
    
    Bug: v8:11141
    Change-Id: I496b619d551aeb584bd6e777c04ed4df076c3ae9
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529143
    Reviewed-by: Andreas Haas <ahaas@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71113}

commit fbb3353c294af96b7586d0309282203c5c628db6
Author: Clemens Backes <clemensb@chromium.org>
Date:   Tue Nov 10 14:04:09 2020 +0100

    [wasm] Fix data race on current_compile_job_
    
    A new compile job can be scheduled from any thread, and
    {current_compile_job_} is documented to be protected by {mutex_}. Hence
    take the mutex before writing that field.
    
    R=thibaudm@chromium.org, ahaas@chromium.org
    
    Bug: v8:11089
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
    Change-Id: I2d3b2c51a7d24c7e827bb7ddc9c76b718c2ccb4c
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529140
    Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71089}

commit f7e484ee29b8b60fc115649101bdad2d07fbb3f1
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Mon Nov 9 17:05:56 2020 +0100

    [heap] Fix a data race in a DCHECK in FreeLinearAllocationArea
    
    The function was using an non-atomic marking state to check the color
    of the object. This is incorrect because concurrent marking may be
    running while the linear allocation area is freed.
    
    Bug: chromium:1139165
    Change-Id: I20ef22908dfd8dcd75858707e884e87658dcb1cb
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2526391
    Auto-Submit: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71057}

commit 249fbbadf0b24754a94bcef62c0fa0c318b7f0ce
Author: Marja Hölttä <marja@chromium.org>
Date:   Fri Nov 6 12:54:07 2020 +0100

    [runtimecallstats] Fix data race in WorkerThreadRuntimeCallStats
    
    Change-Id: I8fff5e5b3d61f1054efdb4fc7f8fa2b50180e418
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2523195
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Commit-Queue: Marja Hölttä <marja@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71011}

commit a024ea4ba731781e8431cbb78bca00ff1f1c5bf0
Author: Clemens Backes <clemensb@chromium.org>
Date:   Mon Oct 5 16:50:59 2020 +0200

    [wasm][fuzzer] Fix data race when setting flags
    
    Fuzzers are executed in their own process, so instead of resetting flags
    after execution, we can just keep the flag values.
    This CL introduces a shared function to enable all staged features,
    without ever resetting the value. This fixes a data race.
    
    R=ahaas@chromium.org
    
    Bug: v8:10979
    Change-Id: I82ea35b887841850edd8b394a3644cf8df1e3bf8
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2449969
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Reviewed-by: Andreas Haas <ahaas@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#70320}

commit 69d507ca5edbf22a1b92277868bd26c579e84c4d
Author: Omer Katz <omerkatz@chromium.org>
Date:   Fri Oct 2 16:45:22 2020 +0200

    cppgc: Various marking data races
    
    This resolves several races identified by concurrent marking tests.
    These include:
    (*) Several instances of not using atomic accesses.
    (*) Synchronizing page on page creation.
    
    Bug: chromium:1056170
    Change-Id: I4a32a44b93a6995a11e3cc75c9446fb8860ae780
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423717
    Commit-Queue: Omer Katz <omerkatz@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#70287}

commit 8b1a3a73faaeea4f97d253daa315141e4e7a579e
Author: Omer Katz <omerkatz@chromium.org>
Date:   Fri Oct 2 14:43:05 2020 +0200

    cppgc: Clear object memory on sweep
    
    We clear during sweep so that we are guaranteed the in-construction bit
    of newly allocated objects is always 0. The lock sweeping uses for
    synchronization assures no data races between clearing and concurrent
    marking.
    
    The only exception to that is debug builds that zap on sweep and clear
    on allocation. This makes it so that dangling references will most
    likely crash in debug builds.
    
    Bug: chromium:1056170
    Change-Id: I12597ef76629ec50c6bfc39dc21b68243c4160ae
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2438530
    Commit-Queue: Omer Katz <omerkatz@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#70283}

commit cebd8b65d8d6b6c9ff877c1a14761a5ef9db4fca
Author: Omer Katz <omerkatz@chromium.org>
Date:   Fri Oct 2 14:52:05 2020 +0200

    cppgc: Mark in construction objects externally
    
    In construction objects don't have anything to sync with on the
    allocation side since they weren't marked as fully constructed yet.
    This could mean the initialization of the marking bit on the mutator
    thread and setting the mark bit on a concurrent thread could race
    (potentially resulting in losing the mark bit when the gc info index
    overwrites it).
    
    This CL fixes this issue by using a set of in construction objects.
    In construction objects are no longer marked. Instead they are pushed
    to the set and the heap object header is marked when they are popped
    from the worklist. Since the set avoids duplicates, this allows us to
    both avoid worklist explosion (due to pushing the same in construction
     object multiple times) and avoid the data race on the mark bit.
    
    This CL uses an unordered_set to record objects. Synchronization uses
    a lock, which could be costly but is not expected to be obtained often.
    
    Bug: chromium:1056170
    Change-Id: I366b59f476c166ff06e15b280df9e846034cc6cf
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2437388
    Commit-Queue: Omer Katz <omerkatz@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#70282}

commit d382dab9e516e6501f30670c0ce3a0574c3d81bd
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Thu Sep 24 12:51:32 2020 +0200

    [test] Only update FLAG_local_heaps if disabled
    
    Avoid data race by only setting FLAG_local_heaps to true if not
    already enabled.
    
    Bug: v8:10315
    Change-Id: Ib562b6d525448f5c088da39bf60928debd97db43
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426610
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#70115}

commit d73a775aeb586810b5cc103719c29da765718c3d
Author: Camillo Bruni <cbruni@chromium.org>
Date:   Tue Sep 22 20:59:16 2020 +0200

    Reland "[d8] Avoid recursive unhandled rejected Promise processing"
    
    This is a reland of 66e4c99c8230f1a07cc59b61743339252561ae52
    
    Move recursive check variable onto PerIsolateData to avoid data races.
    
    Original change's description:
    > [d8] Avoid recursive unhandled rejected Promise processing
    >
    > Bug: chromium:1126309
    > Change-Id: I9d9d33cd151ed8af5ee8af09b8957eae9df2dcb1
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410059
    > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
    > Auto-Submit: Camillo Bruni <cbruni@chromium.org>
    > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#69986}
    
    Bug: chromium:1126309
    Change-Id: I83353e891e8987fa6f828e1efd82968b895638b6
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423708
    Reviewed-by: Marja Hölttä <marja@chromium.org>
    Reviewed-by: Toon Verwaest <verwaest@chromium.org>
    Commit-Queue: Camillo Bruni <cbruni@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#70080}

commit c1e1a6a4aa700e0209bc9487369ba6b7fd761a69
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Mon Sep 21 17:18:16 2020 +0200

    [test] Do not reset log flags
    
    Avoid resetting log flags as this could cause data races with
    allocating background threads.
    
    Bug: v8:10315
    Change-Id: I7be01ff54e349652f182b944ed3f3366d1239ad7
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421814
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#70036}

commit 66f1bf7bc2b081d1354a9880be3d6c05ea093e84
Author: Bill Budge <bbudge@chromium.org>
Date:   Fri Sep 18 18:11:40 2020 +0000

    Revert "[d8] Avoid recursive unhandled rejected Promise processing"
    
    This reverts commit 66e4c99c8230f1a07cc59b61743339252561ae52.
    
    Reason for revert: Causes TSAN data races:
    https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/11350
    
    Original change's description:
    > [d8] Avoid recursive unhandled rejected Promise processing
    >
    > Bug: chromium:1126309
    > Change-Id: I9d9d33cd151ed8af5ee8af09b8957eae9df2dcb1
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410059
    > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
    > Auto-Submit: Camillo Bruni <cbruni@chromium.org>
    > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#69986}
    
    TBR=cbruni@chromium.org,verwaest@chromium.org
    
    Change-Id: I39e6e40ade8d0fd8d3260d41513e68b4763753fe
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Bug: chromium:1126309
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419034
    Reviewed-by: Bill Budge <bbudge@chromium.org>
    Commit-Queue: Bill Budge <bbudge@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#70009}

commit 473b388197eed2191dd2d993a4f807060edc5a1a
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Wed Sep 2 14:00:03 2020 +0200

    Skip no-op stores when enforcing flag implications
    
    The d8 shell modifies compiler flags in PrepareStressRun after isolate
    was already set up and has run some JS code. Updating these flags
    forces recomputation of implications for all flags.
    
    This causes no-op stores to some unrelated flags that are accessed
    from background threads leading to benign data races.
    
    Bug: v8:10315
    Change-Id: I568445d4382ae392970deccbf9588c98e46a4a4e
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390140
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Leszek Swirski <leszeks@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#69672}

commit 35cc3da90245b84974bc48a5f0a4fc03bee85ce2
Author: Clemens Backes <clemensb@chromium.org>
Date:   Wed Aug 26 09:54:17 2020 +0200

    [platform] Fix data race on DefaultJobState::priority_
    
    The {priority_} field is being updated in {DefaultJobState::Join}, under
    {mutex_}. In other places though, it is read unprotected (without
    holding the mutex), leading to data races.
    This CL fixes that by reading the field while holding the mutex and
    using the read priority after releasing the mutex.
    
    Note that the {priority_} field is documented to be protected by
    {mutex_}, so the unprotected read was a bug.
    
    R=ulan@chromium.org
    CC=etiennep@chromium.org
    
    Bug: v8:10822
    Change-Id: I80079f3cb6689e26116ffeb33755c6938c4a2cf1
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377685
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#69571}

commit 59076a3baa50efd3d8a1e88c0331cd6b77c56576
Author: Maya Lekova <mslekova@chromium.org>
Date:   Thu Aug 20 15:23:12 2020 +0000

    Revert "[wasm][ukm] Add tests for Wasm events"
    
    This reverts commit d7b20edcb39cc8348744155d7de33f29ce5302a7.
    
    Reason for revert: Introduces data races - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/32898
    
    Original change's description:
    > [wasm][ukm] Add tests for Wasm events
    >
    > Ensure that events are triggered when a module is decoded, compiled,
    > instantiated and tiered-up.
    >
    > R=​clemensb@chromium.org
    >
    > Bug: chromium:1092417
    >
    > Change-Id: I9dc87957fc03023c5ab1c4f49e865957c8324e1a
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351676
    > Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
    > Reviewed-by: Clemens Backes <clemensb@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#69508}
    
    TBR=clemensb@chromium.org,ecmziegler@chromium.org
    
    Change-Id: I9bcfeda1048939a8142f5003b03feab399f9de96
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Bug: chromium:1092417
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366785
    Reviewed-by: Maya Lekova <mslekova@chromium.org>
    Commit-Queue: Maya Lekova <mslekova@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#69509}

commit 41d2e5c9c0dd505910cd9edb5f9a5e8170ae8fb9
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Wed Aug 19 16:29:24 2020 +0200

    [logging] Make Log::IsEnabled() atomic
    
    With concurrent allocation background threads invoke Log::IsEnabled()
    as well. Fix data race here by making is_enabled_ atomic, such that
    IsEnabled() remains cheap.
    
    After locking the mutex in MessageBuilder, IsEnabled() needs to be
    checked again in case an old value was read. Otherwise we might log
    even though logging was already disabled on another thread.
    
    The other direction where a log message isn't logged is deemed
    acceptable.
    
    Bug: v8:10315
    Change-Id: I32c9dd2e9879fbdb4ca94e080a16ddd875de7c30
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362948
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#69495}

commit f7a4c311723712d4bb7ec92050c4f067eaa6f9f0
Author: Maya Lekova <mslekova@chromium.org>
Date:   Wed Aug 19 12:12:18 2020 +0000

    Revert "[compiler] Replace HeapNumberData with direct reads"
    
    This reverts commit 7964ac86982c4cbf1cae93c7de7866142004bae7.
    
    Reason for revert: Introduces a data race - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/32870
    
    Original change's description:
    > [compiler] Replace HeapNumberData with direct reads
    >
    > Bug: v8:7790
    > Change-Id: I3fbbbd36900146111f83596fd6615a2e4a4f5d33
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362952
    > Commit-Queue: Georg Neis <neis@chromium.org>
    > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
    > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#69474}
    
    TBR=neis@chromium.org,solanes@chromium.org,nicohartmann@chromium.org
    
    Change-Id: Idd17677b2083acf452195a88cb5c363034b43c5f
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Bug: v8:7790
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364493
    Reviewed-by: Maya Lekova <mslekova@chromium.org>
    Commit-Queue: Maya Lekova <mslekova@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#69475}

commit ab8368dfdb094067b54a03ef50d334b3a11a3adc
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Wed Aug 5 14:11:01 2020 +0200

    [heap] Remove PagedSpace::SizeOfObjects
    
    PagedSpace::SizeOfObjects() then returns exactly the same value as
    PagedSpace::Size(). SizeOfObjects() used to deduct the current LAB,
    however this is now more difficult with local heaps. Accessing the
    main thread LAB from concurrent threads causes a data race. Also
    LocalHeaps have their own LAB, which should be deducted as well to be
    uniform with the main thread. However this would be tricky and expensive.
    The simpler solution is to do not deduct the main thread LAB anymore.
    
    Bug: v8:10315
    Change-Id: I3c47e1a65caca9395737251aa694b295e78c7fb5
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336090
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#69245}

commit 94cf4347e4c6f90f12f3b2bbac5ecc8b3ddb26f4
Author: Santiago Aboy Solanes <solanes@chromium.org>
Date:   Tue Jul 28 13:18:24 2020 +0100

    [compiler] Test transition from Uninitialized to kFullTransitionArray
    
    Since we have an uninitialized TransitionArray that we want to insert
    an element (map1), we can't guarantee that said element would exist at
    the point of the search. Then, we search for an element guaranteed not
    to be (map2) and we check that we did not find it.
    
    If we have a data race, this would also trigger it.
    
    Bug: v8:7790
    Change-Id: Ib90044d7c0901d599aed041f608f2c0bce506d67
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319995
    Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
    Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#69099}

commit cb0e1242be508d9be92cb9b40fd12754a230f330
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Tue Jul 14 15:33:34 2020 +0200

    [heap] Make Heap::gc_state_ relaxed atomic
    
    Fix data race between concurrent threads allocating (accessing gc_state_
    that way) and the main thread starting tear down.
    
    Bug: v8:10315
    Change-Id: Icc24811e43268512c8d7fdaf92ecd3fc7b3ecd57
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297390
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#68853}

commit 7f0defa829320a117f68e3b0b477a7024dc5ec29
Author: Dominik Inführ <dinfuehr@chromium.org>
Date:   Wed Jun 24 10:45:05 2020 +0200

    Skip concurrent allocation test
    
    Test has flaky data race and will be fixed after branch to avoid
    regressions.
    
    Bug: v8:10637, v8:10315
    Change-Id: Iddbbd91701aea622803146b84c9a9aa334bda927
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2263155
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#68506}

commit 9743479196fc5cdb930f516d093ed525e3f19200
Author: Clemens Backes <clemensb@chromium.org>
Date:   Thu May 28 15:55:40 2020 +0200

    [wasm][debug] Support multi-threaded stepping
    
    Instead of keeping a single {stepping_frame_} per native module, we now
    keep one frame id per isolate. Hence, each isolate can step through a
    different frame, independent of other isolates.
    The on-stack-replacement of the stepping frame already works on a
    per-isolate basis, since we only replace the return address of a single
    frame, part of the isolate that requested stepping.
    
    The new test (which also executes in a variant with two concurrent
    isolates) revealed some more data races to fix.
    
    R=thibaudm@chromium.org
    
    Bug: v8:10359
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
    Change-Id: I0bb013737162bd09b9f4be9c08990bca7bf736ac
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214838
    Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#68045}

commit 630bad765b4ebf8f70714cbbede2e7288c82694d
Author: Milad Farazmand <miladfar@ca.ibm.com>
Date:   Tue May 19 14:48:12 2020 +0000

    PPC/s390: Reland "[wasm][debug] Fix tier down during streaming compilation"
    
    Port 18ac08d03c3ece6751aa25efa836e79f6959608d
    
    Original Commit Message:
    
        This is a reland of 3cc981cb7a701dc1030445b24ea0f365ce380117 with a
        fix for data race detected by TSan.
    
        Original change's description:
        > [wasm][debug] Fix tier down during streaming compilation
        >
        > If the debugger is enabled while streaming compilation is happening, we
        > won't correctly tier down to Liftoff. This is because during streaming
        > compilation, we always compile for no debugging. Fixing that is a bit
        > tricky, since when the debugger is enabled, functions can either already
        > have finished compiling, or they are currently being compiled, or their
        > wire bytes are not received yet.
        > Instead of handling this correctly while streaming compilation is
        > running, we just recompile the whole module with Liftoff after streaming
        > compilation finished.
        >
        > For testing this, we use the existing tests for async compilation, and
        > enable --wasm-test-streaming, which compiles via the streaming decoder
        > even in the async compilation case.
        >
        > R=thibaudm@chromium.org
        >
        > Bug: v8:10531
        > Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
        > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133
        > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
        > Commit-Queue: Clemens Backes <clemensb@chromium.org>
        > Cr-Commit-Position: refs/heads/master@{#67882}
    
    R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
    BUG=
    LOG=N
    
    Change-Id: I778a10eaba0016a9e897c8f71ac822c6b421350f
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208901
    Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
    Reviewed-by: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#67906}

commit 18ac08d03c3ece6751aa25efa836e79f6959608d
Author: Clemens Backes <clemensb@chromium.org>
Date:   Tue May 19 11:58:56 2020 +0200

    Reland "[wasm][debug] Fix tier down during streaming compilation"
    
    This is a reland of 3cc981cb7a701dc1030445b24ea0f365ce380117 with a
    fix for data race detected by TSan.
    
    Original change's description:
    > [wasm][debug] Fix tier down during streaming compilation
    >
    > If the debugger is enabled while streaming compilation is happening, we
    > won't correctly tier down to Liftoff. This is because during streaming
    > compilation, we always compile for no debugging. Fixing that is a bit
    > tricky, since when the debugger is enabled, functions can either already
    > have finished compiling, or they are currently being compiled, or their
    > wire bytes are not received yet.
    > Instead of handling this correctly while streaming compilation is
    > running, we just recompile the whole module with Liftoff after streaming
    > compilation finished.
    >
    > For testing this, we use the existing tests for async compilation, and
    > enable --wasm-test-streaming, which compiles via the streaming decoder
    > even in the async compilation case.
    >
    > R=thibaudm@chromium.org
    >
    > Bug: v8:10531
    > Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133
    > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
    > Commit-Queue: Clemens Backes <clemensb@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#67882}
    
    Bug: v8:10531, v8:10544
    Change-Id: I884922b6ac55543e6ff9b1046438f6b3abab6f64
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207187
    Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
    Commit-Queue: Clemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#67896}

commit 3b4bafa5a8ec9e53ef5f4cefd22610a2a3f8e82c
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Fri May 15 13:48:38 2020 +0200

    [offthread] Fix a data race in Page::Expand
    
    This is a quick fix that guards the NotifyOldGenerationExpansion call,
    which is not thread-safe outside GC.
    
    Bug: v8:10536
    Change-Id: Iff42fee24242c2e88e0c814ae41766e97181324a
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2204037
    Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#67821}

commit 401190baf0a0e53de2eaa48edd21a877aa710dd9
Author: Andreas Haas <ahaas@chromium.org>
Date:   Tue Apr 14 15:23:05 2020 +0200

    [wasm] Fix return value of concurrent memory.grow
    
    When memory.grow was executed concurrently on multiple threads a data
    race could happen such that two memory.grow operations result in the
    same return value. With this CL the return value of memory.grow is
    unique, given that memory.grow actually grows the memory.
    
    As a concrete example, assume a shared WebAssembly memory initially has
    a size of 100. Assume two threads call memory.grow concurrently with a
    parameter `10`. Then with the existing code, memory would grow correctly
    to a size of 120, but the data race may cause both memory.grow
    operations to return 100. With the change in this CL one memory.grow
    operation would return 100, the other would return 110.
    
    R=gdeepti@chromium.org
    CC=rreverser@google.com
    
    Bug: chromium:1067621
    Change-Id: Ib22b5135714a56799e0818ccb39e5dce327e5f8e
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144113
    Reviewed-by: Ben Smith <binji@chromium.org>
    Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
    Commit-Queue: Andreas Haas <ahaas@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#67135}

commit 31d36add8c5970078feba27b9791033aee107b2f
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Fri Jan 17 18:18:26 2020 +0100

    [heap] Fix data race in Sweeper::MakeIterable
    
    The function can be invoked in a background task and has to take the
    page mutex to sweep it.
    
    Bug: chromium:1040700
    Change-Id: I552fd636ca62f45496dc6c663a0a12d428eb2e20
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007273
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#65847}

commit 1c2141aea5841bc9c863d6efbbbad505fa59bca1
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Fri Jul 19 15:24:32 2019 +0200

    [runtime] Read and write layout descriptor words with atomics
    
    This fixes benign data races reported by TSAN when a shared layout
    descriptor is updated at the end.
    
    Change-Id: I76662cb5fc2b8ab1728e3d1bf42a55a107442eed
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709422
    Reviewed-by: Ben Titzer <titzer@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#62863}

commit de6a07dcdafc34a6bcb87b2814c5a94a4adf8514
Author: Clemens Backes <clemensb@chromium.org>
Date:   Wed Apr 10 16:56:06 2019 +0200

    [wasm] Fix data race on code table
    
    The {code_table_} in {NativeModule} is protected by the
    {allocation_mutex_}. The {code} and {code_table} accessors did not
    acquire this lock though.
    This CL removes the unsafe {code_table} accessor, renames {code} to
    {GetCode} and protects it by a lock.
    
    R=mstarzinger@chromium.org
    
    Bug: v8:9112
    Change-Id: Id2df68460b4c10291a49b4016b9574e02744e8b9
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561315
    Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
    Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#60779}

commit c06cb88bc62796834d491382dae61f2455249122
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Thu Feb 7 14:01:42 2019 +0100

    [heap, serializer] Fix data race in serialization of DescriptorArray
    
    This patch ensures that the serializer does not read the field of
    the DescriptorArray that can be changed concurrently by GC.
    
    Bug: v8:8803
    Change-Id: I849fd2278abd228a46351ab18efb8bfd201ceafc
    Reviewed-on: https://chromium-review.googlesource.com/c/1458239
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#59465}

commit fb89830271424f889d66325776ea8dafb293bb1e
Author: Clemens Backes <clemensb@chromium.org>
Date:   Tue Feb 5 14:22:24 2019 +0100

    [wasm] Fix data race in code logging
    
    In chromium, the platform might delete the task before executing it
    and before fully deregistering the Isolate.
    In that case we need to deregister it from the WasmEngine to avoid a
    data race or use-after-free.
    
    R=mstarzinger@chromium.org
    CC=​​herhut@chromium.org
    
    Bug: v8:8783, chromium:928458
    Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
    Change-Id: Ie94e037f07fbe220505a5d8314b413f24c0990e1
    Reviewed-on: https://chromium-review.googlesource.com/c/1454598
    Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
    Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#59372}

commit 77ed999370e30bec7c11f0395ce4385d86f995ab
Author: Maya Lekova <mslekova@chromium.org>
Date:   Tue Jan 15 16:24:09 2019 +0000

    Revert "Reland "[cpu-profiler] Add more logging to find flaky failure""
    
    This reverts commit 48feba60e6ddca7a210ec57d3b94869aa876d124.
    
    Reason for revert: Some TSAN failures reoccurred - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20TSAN/24456
    
    Original change's description:
    > Reland "[cpu-profiler] Add more logging to find flaky failure"
    >
    > This is a reland of 138bcfc3966f654e5b75089d07cc08975aa26a1c
    >
    > Fixed all the data races and ran TSAN locally to confirm.
    >
    > Original change's description:
    > > [cpu-profiler] Add more logging to find flaky failure
    > >
    > > There is a flaky 5x failure in the tree which I can't reproduce locally.
    > > This extra logging will help flush out what the problem is.
    > >
    > > Bug: v8:8649
    > >
    > > Change-Id: If36d2ce0f4feb398d7d746d69b417bb55a714422
    > > Reviewed-on: https://chromium-review.googlesource.com/c/1402787
    > > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
    > > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    > > Cr-Commit-Position: refs/heads/master@{#58796}
    >
    > Bug: v8:8649
    > Change-Id: I53e293ef85a54d4b2b39aa3b980832031201aa0c
    > Reviewed-on: https://chromium-review.googlesource.com/c/1411633
    > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
    > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#58833}
    
    TBR=jgruber@chromium.org,petermarshall@chromium.org
    
    Change-Id: Icd779b0bd0faf1db76a17736b70617e6b1d6584f
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Bug: v8:8649
    Reviewed-on: https://chromium-review.googlesource.com/c/1412458
    Reviewed-by: Maya Lekova <mslekova@chromium.org>
    Commit-Queue: Maya Lekova <mslekova@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#58834}

commit 48feba60e6ddca7a210ec57d3b94869aa876d124
Author: Peter Marshall <petermarshall@chromium.org>
Date:   Tue Jan 15 15:37:31 2019 +0100

    Reland "[cpu-profiler] Add more logging to find flaky failure"
    
    This is a reland of 138bcfc3966f654e5b75089d07cc08975aa26a1c
    
    Fixed all the data races and ran TSAN locally to confirm.
    
    Original change's description:
    > [cpu-profiler] Add more logging to find flaky failure
    >
    > There is a flaky 5x failure in the tree which I can't reproduce locally.
    > This extra logging will help flush out what the problem is.
    >
    > Bug: v8:8649
    >
    > Change-Id: If36d2ce0f4feb398d7d746d69b417bb55a714422
    > Reviewed-on: https://chromium-review.googlesource.com/c/1402787
    > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
    > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#58796}
    
    Bug: v8:8649
    Change-Id: I53e293ef85a54d4b2b39aa3b980832031201aa0c
    Reviewed-on: https://chromium-review.googlesource.com/c/1411633
    Commit-Queue: Peter Marshall <petermarshall@chromium.org>
    Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#58833}

commit 9a0fcfd848751379291a842e96a657acc845e3f5
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Fri Dec 21 16:45:29 2018 +0100

    [heap] Fix benign data race with string length.
    
    Factory::NewRawOneByteString initializes the string length without
    atomic accessor. This leads to data race if the string is pretenured
    and black allocated because the concurrent marker loads the string
    length before checking the string markbits.
    
    This patch changes the order to check the markbits first.
    
    Bug: v8:8579
    Change-Id: Ic434f7dde9baa6264fe133499d2394c0d4cc5394
    Reviewed-on: https://chromium-review.googlesource.com/c/1388542
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#58465}

commit 21440dd3d456ad09511508bbd4d4ec2aac8d85ec
Author: Clemens Backes <clemensb@chromium.org>
Date:   Fri Dec 14 15:18:27 2018 +0100

    Fix data race on CompilationState callbacks
    
    The vector of callbacks can only be accessed from main threads.
    Otherwise we get flaky data races. Those showed up after removing the
    finisher task (https://crrev.com/c/1335553/2).
    
    R=mstarzinger@chromium.org
    
    Bug: v8:7921
    Change-Id: I0429ae87427601952723f6e3ad1e02eb0e59a6e1
    Reviewed-on: https://chromium-review.googlesource.com/c/1378174
    Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
    Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#58244}

commit 46186c50af46c8211c426d45fba476b2c97acab8
Author: Aseem Garg <aseemgarg@chromium.org>
Date:   Tue Nov 27 15:05:52 2018 -0800

    [wasm] fix data race in futex-emulation wait
    
    waiting_ flag is now set inside a lock to prevent data race. This means
    that waiting_ is false when callback is called at start of wait. To deal
    with the new behavior, NotifyWake now always tries to Notify and sets
    interrupted_ flag which will be handled by any future wait.
    
    R=binji@chromium.org
    BUG=v8:8497
    
    Change-Id: Ia4fd39bcf18875d9be21bafc176ab562b083e68b
    Reviewed-on: https://chromium-review.googlesource.com/c/1351237
    Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
    Reviewed-by: Ben Smith <binji@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#57887}

commit d447883b2f6df52e77408a9bd2d52447ed16d82e
Author: Clemens Backes <clemensb@chromium.org>
Date:   Tue Oct 23 18:46:38 2018 +0200

    [wasm] Fix data race when deleting the CompilationState
    
    When resetting the {unique_ptr} to the {CompilationState} in the
    {NativeModule}, what actually happens is that first the pointer stored
    in the {unique_ptr} is reset to {nullptr}, then the destructor is
    called.
    The destructor of {CompilationState} cancels and waits for background
    compile jobs. While doing so, background compile jobs still try to
    access the {unique_ptr} in the {NativeModule}.
    
    This CL fixes this race by splitting the shutdown in two steps: First,
    cancel and wait the background compile jobs, and only later reset the
    pointer.
    
    R=ahaas@chromium.org
    
    Bug: v8:8359
    No-Tree-Checks: true
    Change-Id: Ifa3bdf3424dfd5a4712d33f8ca85f9382b1766a6
    Reviewed-on: https://chromium-review.googlesource.com/c/1296486
    Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
    Reviewed-by: Andreas Haas <ahaas@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#56913}

commit 2dd15af7008aeeda7b8887f75adbee11da48e2f5
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Mon Oct 15 15:36:28 2018 +0200

    [heap] Fix data race in sweeper.
    
    The race happens when the sweeper is looking up the size of an object
    that had its map replaced concurrently.
    
    The fix is to load the object map using an acquire load so that the
    sweeper observes the initializing stores of the new map.
    
    Bug: v8:8303
    Change-Id: Ifaaef06cb815be7d07b6a574085ee61a466bc1d6
    Reviewed-on: https://chromium-review.googlesource.com/c/1280310
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Reviewed-by: Hannes Payer <hpayer@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#56652}

commit 3ace9cde3f65e92028a30c5951aeff4074878d20
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Fri Oct 12 12:51:44 2018 +0200

    Use synchronized accessors for Map::layout_descriptor field.
    
    This fixes a potential data race that can happen when a freshly
    allocated layout descriptor is set on an existing map while the
    concurrent marker is using the map to visit an object.
    
    Change-Id: If8ff1c9368b24beb15fefe4a78a21e0f0784d2e8
    Reviewed-on: https://chromium-review.googlesource.com/c/1278726
    Reviewed-by: Igor Sheludko <ishell@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#56604}

commit d2967e130d54405be246ab2af18020cc5b2f55a3
Author: Clemens Backes <clemensb@chromium.org>
Date:   Thu Oct 11 17:17:28 2018 +0200

    [d8] Fix data race in DelayedTasksPlatform
    
    Reported here:
    https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20NumFuzz%20-%20TSAN/3108
    
    R=yangguo@chromium.org
    
    Bug: v8:8278
    Change-Id: I78d13cea592678c1ab73b61fd9738f375df565d0
    Reviewed-on: https://chromium-review.googlesource.com/c/1276631
    Reviewed-by: Yang Guo <yangguo@chromium.org>
    Reviewed-by: Maya Lekova <mslekova@chromium.org>
    Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#56576}

commit 0ba3de6089d18648d5021855ae9b502f4128a455
Author: Clemens Backes <clemensb@chromium.org>
Date:   Wed Sep 26 11:46:50 2018 +0200

    [tracing] Fix data race
    
    There is a data race if several background threads check for a tracing
    flag concurrently. Both will call {GetCategoryGroupEnabledInternal}.
    The first one not find the category in the {g_category_group_enabled}
    array, and hence will add it and call {UpdateCategoryGroupEnabledFlag}
    to initialize the flag. The second thread then finds the entry in the
    array and reads it without any synchronization, which is a data race.
    
    Since we do not really care about this race, we just use a
    {Relaxed_Load} to read the field. TSan is fine with that.
    
    R=yangguo@chromium.org
    CC=ofrobots@google.com
    
    Bug: v8:8221
    Change-Id: Ie09141e3d845956d3c487a463f00b7d6cd413513
    Reviewed-on: https://chromium-review.googlesource.com/1245424
    Reviewed-by: Ben Titzer <titzer@chromium.org>
    Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#56256}

commit 2b4c8496d5d8ae0bf106ff0f1354508e97b17868
Author: Clemens Backes <clemensb@chromium.org>
Date:   Fri May 4 14:53:49 2018 +0200

    [wasm] Fix data race in CompilationState
    
    The {baseline_compilation_units_} and {tiering_compilation_units_}
    fields should only be accessed if the {mutex_} is held.
    Also, the number of compilation units is already taken care of inside
    of {RestartBackgroundTasks}, so no need to explicitly pass it.
    
    R=ahaas@chromium.org
    
    Change-Id: I8f36ed141b587ee1bea41291545f39546d8cf24e
    Reviewed-on: https://chromium-review.googlesource.com/1044213
    Reviewed-by: Andreas Haas <ahaas@chromium.org>
    Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#52994}

commit a05c7d51b18a8c2e06e575e13afe6a355e559ce5
Author: Clemens Backes <clemensb@chromium.org>
Date:   Thu Apr 12 09:47:33 2018 +0200

    [wasm] Fix data race on failed_ field
    
    R=ahaas@chromium.org
    
    Bug: chromium:831989, chromium:824681
    Change-Id: I0a8b2cc9f80af5f954bd358c30a3c6d84b6adeae
    Reviewed-on: https://chromium-review.googlesource.com/1009603
    Reviewed-by: Andreas Haas <ahaas@chromium.org>
    Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#52561}

commit 4f43be96ca93874f4a0fb96bd9dc0befc8b85f79
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Tue Feb 27 11:07:26 2018 +0100

    [heap] Fix a data race in Scavenger.
    
    Scavenger::PromoteObject and Scavenger::SemiSpaceCopyObject load and
    dereference the map of the object to compute the alignment.
    
    This is unsafe because the object can be already migrated by another
    thread and the map word can contain the forwarding address.
    
    This patch removes the map load and uses the provided map argument to
    compute the alignment.
    
    Bug: chromium:811278,chromium:807178
    Change-Id: I7343344dc65ae26eefb2602c55dee87bb511bc72
    Reviewed-on: https://chromium-review.googlesource.com/939172
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Yang Guo <yangguo@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#51592}

commit 42ac7fe04bc675fd5d3a620d82e7208d19099e16
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Tue Dec 19 19:23:19 2017 +0100

    [runtime] Make access to FLAG_runtime_stats atomic.
    
    Background tasks read this flag, which creates a data race. This patch
    works around the data races by making the access to the flag atomic.
    
    The actual fix will be to not mutate the flag.
    
    Bug: chromium:794911
    Change-Id: Idcf03b7a1037e876036918418ce989b420784428
    Reviewed-on: https://chromium-review.googlesource.com/834508
    Reviewed-by: Fadi Meawad <fmeawad@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#50215}

commit 5b7e1a01f489fe294650c710b1eef07680c4f546
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Thu Nov 30 18:05:06 2017 +0100

    [heap] Annotate accesses to used instance size field of a map as atomic.
    
    This fixes false positive data race reported by TSAN.
    
    Bug: chromium:790004
    Change-Id: I6335af1735fe9ea77a26cc9919ec4f089b004cdf
    Reviewed-on: https://chromium-review.googlesource.com/800936
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#49766}

commit 2f0b5a2d6da497b61eb1553f923b78fa6f8dbd61
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Wed Nov 22 17:17:29 2017 +0100

    [snapshot] Serizalize initial age for bytecode arrays.
    
    A bytecode array can be serialized while concurrent marking is running
    and aging the bytecode array, which results in a data race.
    
    This patch ensures that the age byte of a bytecode array is not
    accessed during serialization.
    
    Bug: v8:7085
    Change-Id: I83e4b67fbef0754bf75015b4d1b9b660a0cd402f
    Reviewed-on: https://chromium-review.googlesource.com/785677
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Yang Guo <yangguo@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#49612}

commit 0efc615c4ad49583464fa11ad332b4f6277b6e99
Author: Michael Achenbach <machenbach@chromium.org>
Date:   Mon Nov 20 12:30:47 2017 +0000

    Revert "[heap] Concurrently free ArrayBuffer allocations."
    
    This reverts commit b6658adee037de91ed022331994a79c17df5bb09.
    
    Reason for revert: TSAN detects data race when running mksnapshot:
    https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/18354
    
    Original change's description:
    > [heap] Concurrently free ArrayBuffer allocations.
    >
    > Free ArrayBuffer backing stores on a background thread, rather than
    > blocking the main thread after processing. Could potentially cause
    > contention with the array buffer allocator once JS execution resumes.
    >
    > The new ArrayBufferCollector class tracks these dead allocations.
    >
    > Later, the processing of array buffers can happen in parallel.
    >
    > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
    >
    > Bug: v8:6992
    > Change-Id: I49ae4db12ed62d8400ba2bbafeda05a11479d904
    > Reviewed-on: https://chromium-review.googlesource.com/739829
    > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
    > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    > Reviewed-by: Hannes Payer <hpayer@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#49485}
    
    TBR=hpayer@chromium.org,mlippautz@chromium.org,petermarshall@chromium.org
    
    Change-Id: I293440b5f2602ca1c8ad120003f551bc8db6b75f
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Bug: v8:6992
    Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
    Reviewed-on: https://chromium-review.googlesource.com/779199
    Reviewed-by: Michael Achenbach <machenbach@chromium.org>
    Commit-Queue: Michael Achenbach <machenbach@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#49489}

commit 8a1bafaf1a9a2d7f11db510f369d2ecbad2a1137
Author: Andreas Haas <ahaas@chromium.org>
Date:   Wed Nov 15 13:07:22 2017 +0100

    Reland "[platform] Implement TaskRunners in the DefaultPlatform"
    
    There was a data race in the access of the foreground_task_runner_map_.
    I protect each access to foreground_task_runner_map_ with a lock now.
    
    Original change's description:
    > [platform] Implement TaskRunners in the DefaultPlatform
    >
    > This CL implements the TaskRunners in the DefaultPlatform which has been
    > added recently to the platform API. In addition I changed how task
    > posting works on the DefaultPlatform.
    >
    > With this implementation the DefaultPlatform keeps one
    > DefaultForegroundTaskRunner per isolate, plus one
    > DefaultBackgroundTaskRunner. The DefaultPlatform owns these TaskRunners
    > with a shared_ptr, which is also shared with any caller of
    > GetForegroundTaskRunner or GetBackgroundTaskrunner.
    >
    > This CL moves the task management from the DefaultPlatform to the
    > TaskRunners.  The DefaultForegroundTaskRunner owns and manages the the
    > task queue, the delayed task  queue, and the idle task queue. The
    > DefaultBackgroundTaskRunner owns the WorkerThread pool and the
    > background task queue.
    >
    > In addition changed many Task* to std::unique_ptr<Task> to document task
    > ownership.
    >
    > R=rmcilroy@chromium.org
    >
    > Change-Id: Ib9a01f1f45e5b48844a37d801f884210ec3f6c27
    > Reviewed-on: https://chromium-review.googlesource.com/753583
    > Commit-Queue: Andreas Haas <ahaas@chromium.org>
    > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#49354}
    
    Change-Id: Iddccdb07bde1a799815ec6ed6af37082df4987c7
    Reviewed-on: https://chromium-review.googlesource.com/770970
    Commit-Queue: Andreas Haas <ahaas@chromium.org>
    Reviewed-by: Andreas Haas <ahaas@chromium.org>
    Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#49379}

commit 586067e45dd542a117b67ad66d3b14475d8d571f
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Thu Nov 2 14:27:11 2017 +0100

    Reland "[heap] Temporarily disable concurrent marking."
    
    This is a reland of a9a50dc9a89b4e9a78e7b0d048466f8717157a86
    
    Buildbot crashes are fixed by a274fc6.
    
    Original change's description:
    > [heap] Temporarily disable concurrent marking.
    >
    > The 6.3 branch has a data race that is fixed in 6.4 but the fix is too
    > large for back merging.
    >
    > This CL will be back-merged to 6.3 after getting Canary coverage.
    >
    > Concurrent marking will be re-enabled afterwards.
    >
    > Bug: chromium:774644
    > Change-Id: I4112da0e133a637cc4fb52dee2e4c165cdc74f1f
    > Reviewed-on: https://chromium-review.googlesource.com/749811
    > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#49080}
    
    Bug: chromium:774644
    Change-Id: Idf5d179eca25a1481c70c6ca3bccde4869deb544
    Reviewed-on: https://chromium-review.googlesource.com/751271
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#49090}

commit 49c62872dbd11d16373c3e894257348c33267bab
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Thu Nov 2 15:47:42 2017 +0000

    Revert "[heap] Temporarily disable concurrent marking."
    
    This reverts commit a9a50dc9a89b4e9a78e7b0d048466f8717157a86.
    
    Reason for revert: buildbot crashes.
    
    Original change's description:
    > [heap] Temporarily disable concurrent marking.
    >
    > The 6.3 branch has a data race that is fixed in 6.4 but the fix is too
    > large for back merging.
    >
    > This CL will be back-merged to 6.3 after getting Canary coverage.
    >
    > Concurrent marking will be re-enabled afterwards.
    >
    > Bug: chromium:774644
    > Change-Id: I4112da0e133a637cc4fb52dee2e4c165cdc74f1f
    > Reviewed-on: https://chromium-review.googlesource.com/749811
    > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#49080}
    
    TBR=ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org
    
    Change-Id: Ia9d2128c01b811073c1c8f0392eb13b7d7745cd1
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Bug: chromium:774644
    Reviewed-on: https://chromium-review.googlesource.com/751501
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#49083}

commit a9a50dc9a89b4e9a78e7b0d048466f8717157a86
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Thu Nov 2 14:27:11 2017 +0100

    [heap] Temporarily disable concurrent marking.
    
    The 6.3 branch has a data race that is fixed in 6.4 but the fix is too
    large for back merging.
    
    This CL will be back-merged to 6.3 after getting Canary coverage.
    
    Concurrent marking will be re-enabled afterwards.
    
    Bug: chromium:774644
    Change-Id: I4112da0e133a637cc4fb52dee2e4c165cdc74f1f
    Reviewed-on: https://chromium-review.googlesource.com/749811
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#49080}

commit 181c03e9cc7f6b8e2391bfcf4e432556a05a9245
Author: Ben Smith <binji@chromium.org>
Date:   Fri Sep 8 11:01:20 2017 -0700

    Add TSAN annotations for TypedArray accesses
    
    TSAN finds data races in generated JavaScript code that use
    access the SharedArrayBuffer backing store racily. These are races, but
    they are OK in the sense that the JavaScript memory model allows for the
    potential bad behavior they could introduce (e.g. potentially tearing
    reads). Relaxed atomics could be used here instead, but that could
    introduce performance regressions.
    
    This change adds TSAN annotations to the TypedArray reads/writes to
    prevent TSAN from warning about them.
    
    Bug: chromium:722871
    Change-Id: I0776475f02a352b678ade7d32ed6bd4a6be98c36
    Reviewed-on: https://chromium-review.googlesource.com/656509
    Commit-Queue: Ben Smith <binji@chromium.org>
    Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#47929}

commit 5d385417475a4eb5fa43781d6e7a2c56b7c04674
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Thu Aug 17 22:08:21 2017 +0200

    [heap] Fix data race on access to space capacity.
    
    The race happens during evacuation when multiple threads access the
    main space capacity to check CanExpandOldGeneration.
    
    Bug: chromium:694255
    Change-Id: I63dbb71cc3a894f85ee11411a5dc01d53daefa11
    Reviewed-on: https://chromium-review.googlesource.com/618876
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#47414}

commit 6fbbe93c5e60909fbf85933df3f4e4d5e72fb78b
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Mon Jul 31 20:33:50 2017 +0200

    Revert "[heap, runtime] Fix data race in prototype map transition during"
    
    This reverts commit d8846ffd5f9787ef79f85492530f40e7de2d22f3.
    
    Reason: the fix doesn't work, the proper fix is to not mutate the map.
    
    BUG=chromium:694255
    TBR=ishell@chromium.org
    
    Change-Id: Iebef7cd01081145c172902727e0035a8745703b7
    Reviewed-on: https://chromium-review.googlesource.com/594727
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#47020}

commit 962de532f5848675d8e59ba0e2ccc50146bbda05
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Sat Jul 29 15:04:35 2017 +0200

    [heap] Fix data race in IncrementalMarking::NotifyLeftTrimming.
    
    BUG=chromium:694255
    TBR=mlippautz@chromium.org
    
    Change-Id: I7dd9623ff85fcc49f034c71a6f5149f9488a9abb
    Reviewed-on: https://chromium-review.googlesource.com/593010
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#46990}

commit d8846ffd5f9787ef79f85492530f40e7de2d22f3
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Fri Jul 21 14:11:11 2017 +0200

    Reland "[heap, runtime] Fix data race in prototype map transition during"
    
    This reverts commit a9428d527e8f8bc1aeb31929357700f43ef3d46d.
    
    Original change's description:
     > [heap, runtime] Fix data race in prototype map transition during
     > concurrent marking.
     >
     > BUG=chromium:694255
     >
     > Change-Id: I172167623e9deab692fb506d7d4211d210b09a80
     > Reviewed-on: https://chromium-review.googlesource.com/579092
     > Reviewed-by: Igor Sheludko <ishell@chromium.org>
     > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
     > Cr-Commit-Position: refs/heads/master@{#46813}
    
    Change-Id: Ib4b4b989620800ce8a4f4247e4dae2a88c186be9
    Reviewed-on: https://chromium-review.googlesource.com/581194
    Reviewed-by: Igor Sheludko <ishell@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#46819}

commit a9428d527e8f8bc1aeb31929357700f43ef3d46d
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Fri Jul 21 10:34:47 2017 +0000

    Revert "[heap, runtime] Fix data race in prototype map transition during"
    
    This reverts commit b2d1f27209dca47964200bccdad726d445447bb5.
    
    Reason for revert: assertion failure
    
    Original change's description:
    > [heap, runtime] Fix data race in prototype map transition during
    > concurrent marking.
    >
    > BUG=chromium:694255
    >
    > Change-Id: I172167623e9deab692fb506d7d4211d210b09a80
    > Reviewed-on: https://chromium-review.googlesource.com/579092
    > Reviewed-by: Igor Sheludko <ishell@chromium.org>
    > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#46813}
    
    TBR=ulan@chromium.org,ishell@chromium.org
    
    Change-Id: Ida5c66c3e880b9a03ffacbc6f32b1d5b2cfc8260
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Bug: chromium:694255
    Reviewed-on: https://chromium-review.googlesource.com/581287
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#46815}

commit b2d1f27209dca47964200bccdad726d445447bb5
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Thu Jul 20 16:54:35 2017 +0200

    [heap, runtime] Fix data race in prototype map transition during
    concurrent marking.
    
    BUG=chromium:694255
    
    Change-Id: I172167623e9deab692fb506d7d4211d210b09a80
    Reviewed-on: https://chromium-review.googlesource.com/579092
    Reviewed-by: Igor Sheludko <ishell@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#46813}

commit e4b3f6a759b0ca1bfb4ce7d86ffb81803cf05f1b
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Mon Jul 10 19:27:47 2017 +0200

    [heap] Fix data race in JSObject::RawFastDoublePropertyAsBitsAtPut with
    concurrent marking.
    
    The function should use relaxed store similar to other JSObject setters.
    
    BUG=chromium:694255
    
    Change-Id: I032f0763a5f2420d120bce976533aa0007868b97
    Reviewed-on: https://chromium-review.googlesource.com/565573
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#46535}

commit 039849478b2f4145ca57888366f9ce79dccb4aae
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Thu Jun 29 14:01:02 2017 +0200

    [heap] Fix data race with inobject_properties access in concurrent marker.
    
    The race happens when inobject slack tracking is being completed on the
    main thread, which decrements inobject_properties. At the same time
    the concurrent marker is reading inobject_properties via the
    LayoutDescriptorHelper.
    
    BUG=chromium:694255
    
    Change-Id: I4627d66b66c6036d357b9f619e1c602f0bb47d80
    Reviewed-on: https://chromium-review.googlesource.com/555210
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#46319}

commit 2a614f95bd9775996d3f0c3ea7fbd4b385277cb5
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Fri Jun 23 13:58:41 2017 +0200

    [heap] Fix a data race in layout descriptor.
    
    The race happens when the layout descriptor is evacuated at the same
    time as an object that has this layout descriptor is evacuated.
    
    Change-Id: I0a5fc545cf359fdfe738d8b6359713f5ea170986
    Reviewed-on: https://chromium-review.googlesource.com/544953
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#46175}

commit af1c9e345d9376932248f60469742c49b4b074fb
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Wed Jun 21 12:48:39 2017 +0200

    [heap] Fix data race in runtime functions that use std::sort.
    
    BUG=chromium:694255
    
    Change-Id: I52237650b2e80428d21acfa2c4993a07d224b8c5
    Reviewed-on: https://chromium-review.googlesource.com/542819
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#46098}

commit d1c2c8ed8f510dfd32652d2874099ca58f42b828
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Wed Jun 21 10:53:42 2017 +0200

    [heap] Fix a markbit data race in deserializer.
    
    BUG=chromium:694255
    
    Change-Id: Icd949cb6cd3c7405dbdf1933f6239851443f87a8
    Reviewed-on: https://chromium-review.googlesource.com/542616
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#46094}

commit 7e192a91b826ebd27ed7992bf4f8a84596005c50
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Tue Jun 20 17:25:32 2017 +0200

    [heap] Fix data race in Heap::MoveElements.
    
    BUG=chromium:694255
    
    Change-Id: Id15b12ab821de4af7518b658dc63e35bde483312
    Reviewed-on: https://chromium-review.googlesource.com/541325
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#46082}

commit 502ce7e2348294aee6fe0e45f87c102bf030d650
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Tue Jun 20 15:39:39 2017 +0200

    [heap] Fix markbit data races with concurrent marker.
    
    BUG=chromium:694255
    
    Change-Id: I65b4ecc7630ece32e351c1c6acea3960f7b6778b
    Reviewed-on: https://chromium-review.googlesource.com/541380
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#46054}

commit d906f81502fb393daa6eb94e122be2062c59308b
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Fri Jun 9 12:06:11 2017 +0200

    [heap] Fix a map creation data race with concurrent marking.
    
    The race happens when an object transitions to a newly created map.
    The map initializing stores can be reordered after object->set_map(map),
    which will cause the concurrent marker to observe inconsistent map.
    
    The fix is to use store-release when setting the map pointer and
    acquire-load when reading the map in the concurrent marker.
    
    BUG=chromium:694255
    
    Change-Id: I4fd6bc27dd70ff1a30f56a4cec13310ccdd627c8
    Reviewed-on: https://chromium-review.googlesource.com/528118
    Reviewed-by: Hannes Payer <hpayer@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#45876}

commit 25f970370a414a1a50810ab5db5127e8f3352c2d
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Wed Jun 7 14:21:43 2017 +0200

    [heap] Fix more data races in bitmap SetRange and ClearRange.
    
    This patch also changes String body descriptor to use synchronized
    length and adds atomic live_bytes accessor.
    
    BUG=chromium:694255
    
    Change-Id: I41233b2097ec5c6a4ea2c45d4b8febf7ffca155e
    Reviewed-on: https://chromium-review.googlesource.com/527093
    Reviewed-by: Hannes Payer <hpayer@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#45761}

commit 2bed5a290c0ab2b230076e408b9ad1680ddeaa90
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Wed May 31 18:00:04 2017 +0600

    [heap] Handle object creation data races in concurrent marking.
    
    Black allocation is switched on at the start of incremental marking
    if concurrent marking is enabled.
    
    New space objects in the allocation area are handled by the main thread.
    
    BUG=chromium:694255
    
    Change-Id: I694affe11b95f51e2fe79563b2b048aaef982c03
    Reviewed-on: https://chromium-review.googlesource.com/518862
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Reviewed-by: Hannes Payer <hpayer@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#45626}

commit e0dcd1ecea533f1e7b6e218165918dc4c632ebb9
Author: Ulan Degenbaev <ulan@chromium.org>
Date:   Wed May 31 14:13:36 2017 +0600

    [heap] Fix more data races with live bytes in concurrent marking.
    
    BUG=chromium:694255
    
    Change-Id: I7edece8191d85376d3435e799ac64f3cbe814456
    Reviewed-on: https://chromium-review.googlesource.com/519002
    Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#45618}

commit 387e2aca5e4da925f5d156315485ec27bb88c685
Author: Michael Lippautz <mlippautz@chromium.org>
Date:   Wed Mar 15 13:35:21 2017 +0100

    [heap] Use no barrier store forwarding objects during evacuation
    
    This fixes a TSAN data race when writing the forwarding pointer in
    MigrateObject and reading the object as a LayoutDescriptor when trying
    to figure out the layout of another object in parallel.
    
    BUG=chromium:701732
    
    Change-Id: I1e291fa1afb42771244e1346680164de71c3a838
    Reviewed-on: https://chromium-review.googlesource.com/455817
    Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#43826}

commit ce5a46b36409f7de7af717dcfd8f2e1173d29186
Author: ahaas <ahaas@chromium.org>
Date:   Fri Aug 12 03:59:35 2016 -0700

    Revert of [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject. (patchset #3 id:40001 of https://codereview.chromium.org/2229243003/ )
    
    Reason for revert:
    There is a data race in the initialization of the Isolate::random_number_generator()
    
    Original issue's description:
    > [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject.
    >
    > This CL splits CodeGenerator::GenerateCode into two new functions:
    > AssembleCode and FinishCodeObject. AssembleCode does not access or
    > modify the JS heap, which means that AssembleCode can be executed on
    > background threads. FinishCodeObject allocates the generated code object
    > on the JS heap and therefore has to be executed on the main thread.
    >
    > Implementation details:
    > The GenerateCode function has been split just before out-of-line code is
    > assembled. The reason is that code stubs may be generated when
    > out-of-line code is assembled, which potentially allocates these code
    > stubs on the heap.
    >
    > - Parts of initialization of the CodeGenerator has been moved from the
    > constructor to an Initialize function so that we can instantiate an empty
    > CodeGenerator object in PipelineData.
    >
    > R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org
    >
    > Committed: https://crrev.com/03058a2187e32cc4080612181802086527c116a2
    > Cr-Commit-Position: refs/heads/master@{#38604}
    
    TBR=bmeurer@chromium.org,mstarzinger@chromium.org,titzer@chromium.org
    # Skipping CQ checks because original CL landed less than 1 days ago.
    NOPRESUBMIT=true
    NOTREECHECKS=true
    NOTRY=true
    
    Review-Url: https://codereview.chromium.org/2240523003
    Cr-Commit-Position: refs/heads/master@{#38605}

commit 282cdf28ae13fbe6bca5cc4bd35d1f4e37372073
Author: ahaas <ahaas@chromium.org>
Date:   Mon Aug 1 14:04:42 2016 -0700

    [wasm] Use a LazyInstance in wasm-linkage.cc to avoid a data race.
    
    The initialization of static variables that were used originally caused
    a data race because multiple threads tried to initialize the variables
    at the same time. The use of a LazyInstance guarantees that the
    variables get initialized exactly once.
    
    The same problem also existed in c-linkage.cc. There I fixed the problem
    by using a local variable instead of a static variable.
    
    BUG=v8:5242
    R=titzer@chromium.org
    
    Review-Url: https://codereview.chromium.org/2202433003
    Cr-Commit-Position: refs/heads/master@{#38221}

commit 636f1e8e591dde3d71c45740ceda95ceb592cb0e
Author: lpy <lpy@chromium.org>
Date:   Wed May 25 13:22:34 2016 -0700

    Revert of Create libsampler as V8 sampler library. (patchset #24 id:460001 of https://codereview.chromium.org/1922303002/ )
    
    Reason for revert:
    V8 Linux64 TSAN failure because ThreadSanitizer indicated data race.
    
    Original issue's description:
    > Create libsampler as V8 sampler library.
    >
    > This patch does five things:
    >
    > 1. Extracts sampler as libsampler to provide sampling functionality support.
    > 2. Makes SampleStack virtual so embedders can override the behaviour of sample collecting.
    > 3. Removes sampler.[h|cc].
    > 4. Moves sampling thread into log.cc as workaround to keep the --prof functionality.
    > 5. Creates SamplerManager to manage the relationship between samplers and threads.
    >
    > The reason we port hashmap.h is that in debug mode, STL containers are using
    > mutexes from a mutex pool, which may lead to deadlock when using asynchronously
    > signal handler.
    >
    > Currently libsampler is used in V8 temporarily.
    >
    > BUG=v8:4789
    > LOG=n
    >
    > Committed: https://crrev.com/06cc9b7c176a6223971deaa9fbcafe1a05058c7b
    > Cr-Commit-Position: refs/heads/master@{#36527}
    
    TBR=jochen@chromium.org,alph@chromium.org,fmeawad@chromium.org,yangguo@chromium.org
    # Skipping CQ checks because original CL landed less than 1 days ago.
    NOPRESUBMIT=true
    NOTREECHECKS=true
    NOTRY=true
    BUG=v8:4789
    
    Review-Url: https://codereview.chromium.org/2000323007
    Cr-Commit-Position: refs/heads/master@{#36529}

commit be8c688adee75ed028bff949c8ffe1077eea6229
Author: ahaas <ahaas@chromium.org>
Date:   Wed May 11 08:58:05 2016 -0700

    Revert of [wasm] Implement parallel compilation. (patchset #6 id:100001 of https://codereview.chromium.org/1961973002/ )
    
    Reason for revert:
    The ThreadSanitizer finds data races.
    
    Original issue's description:
    > [wasm] Implement parallel compilation.
    >
    > With this CL it is possible to compile a wasm module with multiple
    > threads in parallel. Parallel compilation works as follows:
    >
    > 1)   The main thread allocates a compilation unit for each wasm function.
    > 2)   The main thread spawns WasmCompilationTasks which run on the
    >      background threads.
    > 3.a) The background threads and the main thread pick one compilation unit
    >      at a time and execute the parallel phase of the compilation unit.
    >      After finishing the execution of the parallel phase, the compilation
    >      unit is stored in a result queue.
    > 3.b) If the result queue contains a compilation unit, the main thread
    >      dequeues it and finishes its compilation.
    > 4)   After the execution of the parallel phase of all compilation units has
    >      started, the main thread waits for all WasmCompilationTasks to finish.
    > 5)   The main thread finalizes the compilation of the module.
    >
    > I'm going to add some additional tests before committing this CL.
    >
    > R=titzer@chromium.org, bmeurer@chromium.org, mlippautz@chromium.org, mstarzinger@chromium.org
    >
    > Committed: https://crrev.com/17215438659d8ff2d7d55f95226bf8a1477ccd79
    > Cr-Commit-Position: refs/heads/master@{#36178}
    
    TBR=bmeurer@chromium.org,mlippautz@chromium.org,mstarzinger@chromium.org,titzer@chromium.org
    # Skipping CQ checks because original CL landed less than 1 days ago.
    NOPRESUBMIT=true
    NOTREECHECKS=true
    NOTRY=true
    
    Review-Url: https://codereview.chromium.org/1965243003
    Cr-Commit-Position: refs/heads/master@{#36182}

commit 779aa924f6d0066fe134ccbdc2abb9e5e15e100f
Author: mlippautz <mlippautz@chromium.org>
Date:   Mon Jan 11 04:58:03 2016 -0800

    [heap] Adjust condition for AdjustLiveBytes to avoid concurrent access w/ sweeper
    
    A concurrent sweeper thread can access the same markbit cell as the main thread
    during right trimming a fixed array, resulting in a data race on a markbit cell.
    Previously we checked whether we were currently marking incrementally, filtering
    out this case.
    
    The current check has the benefit of keeping live_bytes accurate (modulo other
    bugs) until the sweeper starts.
    
    BUG=chromium:576193
    LOG=N
    
    Review URL: https://codereview.chromium.org/1576853002
    
    Cr-Commit-Position: refs/heads/master@{#33203}

commit 218948e5f2b62ade15d4f6b969392989b3e66dba
Author: vogelheim <vogelheim@chromium.org>
Date:   Fri Aug 21 09:20:50 2015 -0700

    Revert of Concurrently unmap free pages. (patchset #4 id:60001 of https://codereview.chromium.org/1303263002/ )
    
    Reason for revert:
    Several tests on V8 Linux64 TSAN bot are broken, due to data races between allocation & GC.
    
    A bisect points to this CL, and the CL description sounds pertinent to the observed breakage.
    
    Original issue's description:
    > Concurrently unmap free pages.
    >
    > BUG=
    >
    > Committed: https://crrev.com/d1aeb45d96123d47023066b244c0f450fbe57d2d
    > Cr-Commit-Position: refs/heads/master@{#30306}
    
    TBR=mlippautz@chromium.org,hpayer@chromium.org
    NOPRESUBMIT=true
    NOTREECHECKS=true
    NOTRY=true
    BUG=
    
    Review URL: https://codereview.chromium.org/1306213002
    
    Cr-Commit-Position: refs/heads/master@{#30310}

commit e045b78d8ed1d0450f70baa44d16eda78f680188
Author: vogelheim <vogelheim@chromium.org>
Date:   Tue Aug 4 07:31:41 2015 -0700

    Avoid data race when writing Shell::options.script_executed.
    
    The race occurred when Workers were used. Since Workers call
    Shell::ExecuteString from a different thread, TSAN (correctly) flags
    this as a racy write. Solution would be to either synchronize the writes,
    or to 'lift' the write higher up in the call stack and only write the flag
    from the main thread. This implements this latter solution.
    
    These methods call Shell::ExecuteString, but do *not* set script_executed:
    - ExecuteInThread: Can only occur is JS has already been executed.
    - Shell::Load: Callback for JS; so JS has already been executed when
                   we get there.
    - Shell::RunShell: Interactive shell. We no longer need script_executed once
                       we're here.
    
    BUG=v8:4330
    LOG=N
    
    Review URL: https://codereview.chromium.org/1258303004
    
    Cr-Commit-Position: refs/heads/master@{#30003}

commit 41d74f21f11927352994d9d6ac385477e4a9be6d
Author: ulan <ulan@chromium.org>
Date:   Mon Mar 16 03:16:59 2015 -0700

    Fix data race in Isolate::CheckDetachedContextsAfterGC
    
    BUG=chromium:462908
    LOG=NO
    
    Review URL: https://codereview.chromium.org/1010713002
    
    Cr-Commit-Position: refs/heads/master@{#27211}

commit 5e1cd18d945edca5bdd823db3a831a5762d2f255
Author: rossberg@chromium.org <rossberg@chromium.org>
Date:   Tue Oct 21 12:57:19 2014 +0000

    Fix data race with interface caching
    
    R=bmeurer@chromium.org
    BUG=421634
    LOG=N
    
    Review URL: https://codereview.chromium.org/667703002
    
    git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24774 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

commit ba9bf72a2a725a0a749e67a3b5095019c72cb2f8
Author: jochen@chromium.org <jochen@chromium.org>
Date:   Wed Oct 8 09:01:43 2014 +0000

    Avoid unnecessary data race on FLAG_track_double_fields
    
    BUG=none
    R=svenpanne@chromium.org
    LOG=n
    
    Review URL: https://codereview.chromium.org/639723002
    
    git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24456 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

commit 73733bb3eb8f5f1cb375c34d5b94182326312b4c
Author: jochen@chromium.org <jochen@chromium.org>
Date:   Wed Oct 8 08:17:04 2014 +0000

    Fix data races and leaks related to v8::Lockers
    
    BUG=v8:3618
    R=ishell@chromium.org, svenpanne@chromium.org
    LOG=n
    
    Review URL: https://codereview.chromium.org/637263002
    
    git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24453 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

commit d78fab455a8ba597eeb4ef32da113f9c5b96bf19
Author: jochen@chromium.org <jochen@chromium.org>
Date:   Wed Oct 8 07:41:28 2014 +0000

    Fix data race in cctest/test-api/RegExpInterruption
    
    BUG=v8:3615
    R=yangguo@chromium.org
    LOG=n
    
    Review URL: https://codereview.chromium.org/634523003
    
    git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24451 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

commit be69c78e6dda611aeb0a5c5abc8c96efce25fc45
Author: jochen@chromium.org <jochen@chromium.org>
Date:   Tue Oct 7 16:11:31 2014 +0000

    Fix data race on Debug::thread_local_.current_debug_scope_
    
    BUG=v8:3614
    R=yangguo@chromium.org
    LOG=n
    
    Review URL: https://codereview.chromium.org/631223004
    
    git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24441 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

commit 7f61f657ce06d60733646b1da06ef45d4ce1f337
Author: jochen@chromium.org <jochen@chromium.org>
Date:   Tue Oct 7 14:45:17 2014 +0000

    Fix data race on CpuProfiler::running_
    
    BUG=v8:3613
    R=yangguo@chromium.org
    LOG=n
    
    Review URL: https://codereview.chromium.org/632313002
    
    git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24439 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

commit 67f43055d2286dccc44b3aae378dee4b2dedcdda
Author: yangguo@chromium.org <yangguo@chromium.org>
Date:   Wed Oct 1 11:41:19 2014 +0000

    Fix data race when concurrent compilation is aborted due to dependency change.
    
    R=marja@chromium.org
    BUG=chromium:419189
    LOG=N
    
    Review URL: https://codereview.chromium.org/616263003
    
    git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24361 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

commit 97681be4e51c99bf58773c0f138b0cc3a8487c1a
Author: yurys@chromium.org <yurys@chromium.org@ce2b1a6d-e550-0410-aec6-3dcde31c8c00>
Date:   Thu Jul 18 13:42:04 2013 +0000

    Fix data race in SamplingCircularQueue
    
    This change fixes data race described in the bug by adding Acquire_Load to SamplingCircularQueue::StartDequeue and Acquire_Store to SamplingCircularQueue::Enqueue.
    
    Also the queue implementation imposed a constraint on the records it stored: the first AtomicWord in each record was a marker. For that purpose TickSampleEventRecord had filter field of type int. This approach is error prone, e.g. on x64 sizeof(AtomicWord) is 8 while sizeof(int) is 4. Moreover the queue needs such marker only at the beginning of chunk. I changed the queue so that it stores the marker explicitly as the first Cell in chunk and removed the filter field.
    
    BUG=251218
    R=loislo@chromium.org, yangguo@chromium.org
    
    Review URL: https://codereview.chromium.org/19642002
    
    git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15750 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

commit 41cac47d570a4667fac13de15965f476dcdcb8c9
Author: yangguo@chromium.org <yangguo@chromium.org@ce2b1a6d-e550-0410-aec6-3dcde31c8c00>
Date:   Fri Jun 28 11:24:27 2013 +0000

    Avoid data race in debug mode on the parallel thread.
    
    R=jkummerow@chromium.org
    BUG=
    
    Review URL: https://codereview.chromium.org/18194004
    
    git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15376 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

commit 3b53f7dc61e347f2fdcc0e2bde252b73ec76b877
Author: yurys@chromium.org <yurys@chromium.org@ce2b1a6d-e550-0410-aec6-3dcde31c8c00>
Date:   Thu Jun 20 06:23:34 2013 +0000

    Fix data race in v8::internal::UnboundQueue
    
    This change modifies memory accesses to ensure proper load/store ordering.
    
    BUG=249750
    R=dvyukov@google.com, jkummerow@chromium.org
    
    Review URL: https://codereview.chromium.org/17294004
    
    git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15219 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

commit d573e3b39d1506da7a1cf56b96ea619ff0087060
Author: iposva@chromium.org <iposva@chromium.org@ce2b1a6d-e550-0410-aec6-3dcde31c8c00>
Date:   Mon Jul 27 05:31:30 2009 +0000

    Landing patch for Timur Iskhodzhanov.
    Reviewed at http://codereview.chromium.org/160099
    
    The original MacOSMutex constructor makes data race detectors a little
    bit crazy. Also, the new version is simpler and easier to understand.
    
    
    
    git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2535 ce2b1a6d-e550-0410-aec6-3dcde31c8c00