1. 16 Oct, 2020 23 commits
    • Michael Lippautz's avatar
      Reland "cppgc-js: Add snapshot for C++ objects" · 063d56e7
      Michael Lippautz authored
      This reverts commit fba14bde.
      
      Reland fixes:
      - const vector<const string> -> const vector<string>
      
      Original message:
      The following implements a snapshotting algorithm for C++ objects that
      also filters strongly-connected components (SCCs) of only "hidden"
      objects that are not (transitively) referencing any non-hidden
      objects.
      
      C++ objects come in two versions.
      a. Named objects that have been assigned a name through NameProvider.
      b. Unnamed objects, that are potentially hidden if the build
         configuration requires Oilpan to hide such names. Hidden objects have
         their name set to NameProvider::kHiddenName.
      
      The main challenge for the algorithm is to avoid blowing up the final
      object graph with hidden nodes that do not carry information. For that
      reason, the algorithm filters SCCs of only hidden objects, e.g.:
        ...  -> (object) -> (object) -> (hidden) -> (hidden)
      In this case the (hidden) objects are filtered from the graph. The
      trickiest part is maintaining visibility state for objects referencing
      other objects that are currently being processed.
      
      Main algorithm idea (two passes):
      1. First pass marks all non-hidden objects and those that transitively
         reach non-hidden objects as visible. Details:
         - Iterate over all objects.
         - If object is non-hidden mark it as visible and also mark parent
           as visible if needed.
         - If object is hidden, traverse children as DFS to find non-hidden
           objects. Post-order process the objects and mark those objects as
           visible that have child nodes that are visible themselves.
         - Maintain an epoch counter (StateStorage::state_count_) to allow
           deferring the visibility decision to other objects in the same
           SCC. This is similar to the "lowlink" value in Tarjan's algorithm
           for SCC.
         - After the first pass it is guaranteed that all deferred
           visibility decisions can be resolved.
      2. Second pass adds nodes and edges for all visible objects.
         - Upon first checking the visibility state of an object, all deferred
           visibility states are resolved.
      
      For practical reasons, the recursion is transformed into an iteration.
      We do not use plain Tarjan's algorithm to avoid another pass over
      all nodes to create SCCs.
      
      Follow ups:
      1. Adding wrapper nodes for cpp objects that are wrappables for V8
         wrappers.
      2. Adding detachedness information.
      
      Bug: chromium:1056170
      Change-Id: Ib47df5c912c57d644d052f209276e9d926cece0f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480362
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70577}
      063d56e7
    • Clemens Backes's avatar
      Revert "[heap] Introduce new state in CollectionBarrier" · f35fef14
      Clemens Backes authored
      This reverts commit 8358ab49.
      
      Reason for revert: TSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33730
      
      Original change's description:
      > [heap] Introduce new state in CollectionBarrier
      >
      > Introduce new state kCollectionStarted in CollectionBarrier. This state
      > is used during Heap::PerformGarbageCollection. It stops threads from
      > requesting GC when the GC was already started. This happens because a
      > background thread only requests the GC after it parked itself - the GC
      > could be started in-between those two events.
      >
      > Bug: v8:10315
      > Change-Id: I59cf3d4ea41c7a2c37ffce89c5b057221a2499e0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474858
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70572}
      
      TBR=ulan@chromium.org,dinfuehr@chromium.org
      
      Change-Id: Ia67b1cbb931ce1b965876c7a1bbb09f48b8c7b43
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10315
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480563Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70576}
      f35fef14
    • Etienne Pierre-doray's avatar
      [Heap]: Young generation marking uses Jobs. · 696eeb39
      Etienne Pierre-doray authored
      Replaces ItemParallelJob by std::vector to hold marking items.
      IndexGenerator is used to iterate over evacuation items.
      slots_ is moved from items to YoungGenerationMarkingTask to reduce
      synchronisation.
      
      Change-Id: Iac7aba215e8ba545c12a9ab6c810d343234fbbbf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440830
      Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70575}
      696eeb39
    • Etienne Pierre-doray's avatar
      [wasm] Avoid lock in BackgroundCompileToken · e6b2d673
      Etienne Pierre-doray authored
      Most code protected by compilation_scope_mutex_ is already either thread
      safe, or could run in parallel. Removing lock reduces contention.
      Note that weak_ptr::lock is atomic and thus still prevents deletion
      of NativeModule&CompilationStateImpl for the scope of
      BackgroundCompileScope.
      Related changes:
      - BackgroundCompileToken is deleted and publish_queue is moved to
        CompilationStateImpl.
      - Some of the (non thread-safe) logic in publish_results is moved into
        PublishCompilationResults so that it is serialized to 1 thread
        running publisher.
      - cancellation is handled by an atomic bool and is no longer
        synchronized. This means that compilation may be cancelled while
        a worker thread is still running. That thread would only
        stop once it reaches a new BackgroundCompileScope.
      
      Change-Id: I9651e924857c583d1a0fe5b9ffa99bfd01a8bda4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442192Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70574}
      e6b2d673
    • Ross McIlroy's avatar
      Reland "[TurboProp] Avoid marking the output of a call live in its catch handler" · 0403beb4
      Ross McIlroy authored
      This is a reland of cdc8d9a5
      
      Skipped tests on gc_stress and fixed CONSTEXPR_DCHECK for gcc.
      
      Original change's description:
      > [TurboProp] Avoid marking the output of a call live in its catch handler
      >
      > The output of a call won't be live if an exception is thrown while the
      > call is on the stack and we unwind to a catch handler.
      >
      > BUG=chromium:1138075,v8:9684
      >
      > Change-Id: I95bf535bac388940869eb213e25565d64fe96df1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70562}
      
      Bug: chromium:1138075
      Bug: v8:9684
      Change-Id: I685c94ee2ffcf06658df07fcef06f58c4f01f54b
      Cq-Include-Trybots: luci.v8.try:v8_linux64_gcc_compile_dbg
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479009
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70573}
      0403beb4
    • Dominik Inführ's avatar
      [heap] Introduce new state in CollectionBarrier · 8358ab49
      Dominik Inführ authored
      Introduce new state kCollectionStarted in CollectionBarrier. This state
      is used during Heap::PerformGarbageCollection. It stops threads from
      requesting GC when the GC was already started. This happens because a
      background thread only requests the GC after it parked itself - the GC
      could be started in-between those two events.
      
      Bug: v8:10315
      Change-Id: I59cf3d4ea41c7a2c37ffce89c5b057221a2499e0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474858
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70572}
      8358ab49
    • Maya Lekova's avatar
      Revert "cppgc-js: Add snapshot for C++ objects" · fba14bde
      Maya Lekova authored
      This reverts commit 02849fd9.
      
      Reason for revert: Breaks Win64 MSVC bot and closes the tree - https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/15416
      
      Original change's description:
      > cppgc-js: Add snapshot for C++ objects
      >
      > The following implements a snapshotting algorithm for C++ objects that
      > also filters strongly-connected components (SCCs) of only "hidden"
      > objects that are not (transitively) referencing any non-hidden
      > objects.
      >
      > C++ objects come in two versions.
      > a. Named objects that have been assigned a name through NameProvider.
      > b. Unnamed objects, that are potentially hidden if the build
      >    configuration requires Oilpan to hide such names. Hidden objects have
      >    their name set to NameProvider::kHiddenName.
      >
      > The main challenge for the algorithm is to avoid blowing up the final
      > object graph with hidden nodes that do not carry information. For that
      > reason, the algorithm filters SCCs of only hidden objects, e.g.:
      >   ...  -> (object) -> (object) -> (hidden) -> (hidden)
      > In this case the (hidden) objects are filtered from the graph. The
      > trickiest part is maintaining visibility state for objects referencing
      > other objects that are currently being processed.
      >
      > Main algorithm idea (two passes):
      > 1. First pass marks all non-hidden objects and those that transitively
      >    reach non-hidden objects as visible. Details:
      >    - Iterate over all objects.
      >    - If object is non-hidden mark it as visible and also mark parent
      >      as visible if needed.
      >    - If object is hidden, traverse children as DFS to find non-hidden
      >      objects. Post-order process the objects and mark those objects as
      >      visible that have child nodes that are visible themselves.
      >    - Maintain an epoch counter (StateStorage::state_count_) to allow
      >      deferring the visibility decision to other objects in the same
      >      SCC. This is similar to the "lowlink" value in Tarjan's algorithm
      >      for SCC.
      >    - After the first pass it is guaranteed that all deferred
      >      visibility decisions can be resolved.
      > 2. Second pass adds nodes and edges for all visible objects.
      >    - Upon first checking the visibility state of an object, all deferred
      >      visibility states are resolved.
      >
      > For practical reasons, the recursion is transformed into an iteration.
      > We do not use plain Tarjan's algorithm to avoid another pass over
      > all nodes to create SCCs.
      >
      > Follow ups:
      > 1. Adding wrapper nodes for cpp objects that are wrappables for V8
      >    wrappers.
      > 2. Adding detachedness information.
      >
      > Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962
      > Bug: chromium:1056170
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70567}
      
      TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
      
      Change-Id: I64a2cf2259bdaed81f6e0f92bdcc7a1f0df4d197
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1056170
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479471Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70571}
      fba14bde
    • Igor Sheludko's avatar
      [runtime] Fix sorted order of DescriptorArray entries · 518d67ad
      Igor Sheludko authored
      ... and add respective regression tests.
      
      This CL also adds similar regression tests for TransitionArray but it
      doesn't have the same issue as DescriptorArray.
      
      Bug: chromium:1133527
      Change-Id: I668a90f126d76af0a39816ce8697cb29bc65d01b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465833Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70570}
      518d67ad
    • Pierre Langlois's avatar
      [heap] Make maximum regular code object size a runtime value. · f4376ec8
      Pierre Langlois authored
      Executable V8 pages include 3 reserved OS pages: one for the writable
      header and two as guards. On systems with 64k OS pages, the amount of
      allocatable space left for objects can then be quite smaller than the
      page size, only 64k for each 256k page.
      
      This means regular code objects cannot be larger than 64k, while the
      maximum regular object size is fixed to 128k, half of the page size. As
      a result code object never reach this limit and we can end up filling
      regular pages with few large code objects.
      
      To fix this, we change the maximum code object size to be runtime value,
      set to half of the allocatable space per page. On systems with 64k OS
      pages, the limit will be 32k.
      
      Alternatively, we could increase the V8 page size to 512k on Arm64 linux
      so we wouldn't waste code space. However, systems with 4k OS pages are
      more common, and those with 64k pages tend to have more memory available
      so we should be able to live with it.
      
      Bug: v8:10808
      Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Cr-Commit-Position: refs/heads/master@{#70569}
      f4376ec8
    • Ulan Degenbaev's avatar
      Reland "[heap] Refactor marking weak object worklists" · fed3ab6c
      Ulan Degenbaev authored
      This is a reland of ff61743f
      
      Original change's description:
      > [heap] Refactor marking weak object worklists
      >
      > This CL extracts weak object worklist related code into separate files
      > and uses a macro to specify all weak object worklists in a generic way.
      >
      > The motivation of the refactoring is twofold:
      > 1) We can now enforce that each weak object worklist is updated after
      >    Scavenge. (Forgetting to define the update function causes a link
      >    time error.)
      > 2) The reduced boilerplate will be useful for transitioning to the
      >    new ::heap::base::Worklist.
      >
      > Change-Id: Ic80a7ccca010c09370d6525f43d78de24192f8ea
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442624
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70308}
      
      Change-Id: I8a9f39e53ef4123dd28a1da6f7992cdff341f694
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461741Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70568}
      fed3ab6c
    • Michael Lippautz's avatar
      cppgc-js: Add snapshot for C++ objects · 02849fd9
      Michael Lippautz authored
      The following implements a snapshotting algorithm for C++ objects that
      also filters strongly-connected components (SCCs) of only "hidden"
      objects that are not (transitively) referencing any non-hidden
      objects.
      
      C++ objects come in two versions.
      a. Named objects that have been assigned a name through NameProvider.
      b. Unnamed objects, that are potentially hidden if the build
         configuration requires Oilpan to hide such names. Hidden objects have
         their name set to NameProvider::kHiddenName.
      
      The main challenge for the algorithm is to avoid blowing up the final
      object graph with hidden nodes that do not carry information. For that
      reason, the algorithm filters SCCs of only hidden objects, e.g.:
        ...  -> (object) -> (object) -> (hidden) -> (hidden)
      In this case the (hidden) objects are filtered from the graph. The
      trickiest part is maintaining visibility state for objects referencing
      other objects that are currently being processed.
      
      Main algorithm idea (two passes):
      1. First pass marks all non-hidden objects and those that transitively
         reach non-hidden objects as visible. Details:
         - Iterate over all objects.
         - If object is non-hidden mark it as visible and also mark parent
           as visible if needed.
         - If object is hidden, traverse children as DFS to find non-hidden
           objects. Post-order process the objects and mark those objects as
           visible that have child nodes that are visible themselves.
         - Maintain an epoch counter (StateStorage::state_count_) to allow
           deferring the visibility decision to other objects in the same
           SCC. This is similar to the "lowlink" value in Tarjan's algorithm
           for SCC.
         - After the first pass it is guaranteed that all deferred
           visibility decisions can be resolved.
      2. Second pass adds nodes and edges for all visible objects.
         - Upon first checking the visibility state of an object, all deferred
           visibility states are resolved.
      
      For practical reasons, the recursion is transformed into an iteration.
      We do not use plain Tarjan's algorithm to avoid another pass over
      all nodes to create SCCs.
      
      Follow ups:
      1. Adding wrapper nodes for cpp objects that are wrappables for V8
         wrappers.
      2. Adding detachedness information.
      
      Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962
      Bug: chromium:1056170
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70567}
      02849fd9
    • Michael Achenbach's avatar
      [fuzzing] Don't expose OS methods when fuzzing · 082ada05
      Michael Achenbach authored
      Fuzzers might randomly call OS methods to create or remove
      directories. This leads to spurious results when doing differential
      fuzzing, but it could be potentially harmful to the system during
      normal fuzzing.
      
      This drops OS methods in d8 on fuzzers.
      
      Bug: chromium:1138594
      Change-Id: Ia3a8c4e3d06c76ccdc50ead1d361338e13ddf1bb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474790Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70566}
      082ada05
    • Victor Gomes's avatar
      [cleanup] Remove parameters accessors from CommonFrame · ee17d001
      Victor Gomes authored
      Change-Id: Ic54046824d4f3c98caa8381d2ece46c9985a2b98
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2475734Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Auto-Submit: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70565}
      ee17d001
    • Michael Achenbach's avatar
      Revert "[TurboProp] Avoid marking the output of a call live in its catch handler" · 56b55f3f
      Michael Achenbach authored
      This reverts commit cdc8d9a5.
      
      Reason for revert: The regression test is too slow:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/30454
      
      Also gcc failures:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20gcc%20-%20debug/9528
      
      Original change's description:
      > [TurboProp] Avoid marking the output of a call live in its catch handler
      >
      > The output of a call won't be live if an exception is thrown while the
      > call is on the stack and we unwind to a catch handler.
      >
      > BUG=chromium:1138075,v8:9684
      >
      > Change-Id: I95bf535bac388940869eb213e25565d64fe96df1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70562}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org
      
      Change-Id: I0f6b9378d516a70401fc429fb3612bbf962b0fb2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1138075
      Bug: v8:9684
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479007Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70564}
      56b55f3f
    • Zhao Jiazhong's avatar
      [mips64][builtins] Fix removing all arguments from the stack · 8557840b
      Zhao Jiazhong authored
      The sp register's value should be modified to drop all the args
      from the stack.
      
      Change-Id: I7410d325523427d765eb0640e14acede5589284f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479222Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70563}
      8557840b
    • Ross McIlroy's avatar
      [TurboProp] Avoid marking the output of a call live in its catch handler · cdc8d9a5
      Ross McIlroy authored
      The output of a call won't be live if an exception is thrown while the
      call is on the stack and we unwind to a catch handler.
      
      BUG=chromium:1138075,v8:9684
      
      Change-Id: I95bf535bac388940869eb213e25565d64fe96df1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70562}
      cdc8d9a5
    • Omer Katz's avatar
      cppgc: Add TraceStrongly to Visitor · cb802efb
      Omer Katz authored
      Align the library with the current blink implementation.
      TraceStrongly takes a WeakMember and strongifies it so that the
      referenced objects is retained.
      This is used in blink during tracing of some weak collections.
      
      Bug: chromium:1056170
      Change-Id: I306f84fc37a856d309bccc7f544750abb2bdc7c9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479003
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Auto-Submit: Omer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70561}
      cb802efb
    • Dominik Inführ's avatar
      Reland "[compiler, heap] Create LocalHeap outside of ExecuteJob" · de914c75
      Dominik Inführ authored
      This is a reland of 44708a5b
      
      Original change's description:
      > [compiler, heap] Create LocalHeap outside of ExecuteJob
      >
      > Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
      > pass its reference as argument to ExecuteJob. This allows us to create
      > LocalHeap differently for the main and background thread, e.g. by
      > passing an additional argument to the constructor in the future.
      > It will be required in the future anyways when the main thread will
      > have its own LocalHeap/LocalIsolate.
      >
      > Extending the scope of LocalHeap, also made
      > HandleBase::IsDereferenceAllowed more precise and uncovered two
      > potential issues: heap accesses in
      > OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
      > with --code-comments.
      >
      > LocalHeap can now be created in the parked state. Also fixed a data
      > race with LocalHeap's destructor publishing write barrier entries
      > without holding the lock.
      >
      > Bug: v8:10315
      > Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70521}
      
      Bug: v8:10315
      Change-Id: I4c459fd6dfb98d47fc9941c0dc6864bf5a1d2d3e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474788Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70560}
      de914c75
    • Nico Hartmann's avatar
      Revert "[debugger] Try to trigger pause-on-oom flakes with an extra printf" · 812a16da
      Nico Hartmann authored
      This reverts commit 8f7e9158.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20node.js%20integration%20ng/10707?
      
      Original change's description:
      > [debugger] Try to trigger pause-on-oom flakes with an extra printf
      >
      > We have an issue that we can't repro locally. Enable back the
      > pause-on-oom tests with an extra printf with DEBUG. We will be able to
      > better assess the failures when they appear on the bot.
      >
      > Bug: v8:10876
      > Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70558}
      
      TBR=rmcilroy@chromium.org,petermarshall@chromium.org,solanes@chromium.org
      
      Change-Id: I1b8a146d9496e889957636456b383f8d496658dc
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10876
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479004Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70559}
      812a16da
    • Santiago Aboy Solanes's avatar
      [debugger] Try to trigger pause-on-oom flakes with an extra printf · 8f7e9158
      Santiago Aboy Solanes authored
      We have an issue that we can't repro locally. Enable back the
      pause-on-oom tests with an extra printf with DEBUG. We will be able to
      better assess the failures when they appear on the bot.
      
      Bug: v8:10876
      Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70558}
      8f7e9158
    • Jakob Gruber's avatar
      [cleanup] Various misc. cleanups · dcf467a8
      Jakob Gruber authored
      - Use kNoBuiltinId instead of literal -1.
      - Remove support for non-embedded builtins.
      - Update Code object layout comment.
      
      Bug: v8:10933
      Change-Id: Ie75c6ccc0a0f19348ae214249a8fc81f7e91df0c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474115
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70557}
      dcf467a8
    • Jakob Gruber's avatar
      [snapshot] Dedicated code start symbol for sampling profiler · 7a9f2a46
      Jakob Gruber authored
      The UMA sampling profiler prefers unique symbol addresses, otherwise
      disambiguation is fairly arbitrary (lexicographic).
      
      To this end, introduce a dedicated symbol v8_code_start_for_profiler_
      at a unique address (i.e. no other symbol is located at this address).
      
      Bug: v8:6666
      Change-Id: Iec13ccac64efc7ac3f63e29632ee8f6300bcb76b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464926
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70556}
      7a9f2a46
    • v8-ci-autoroll-builder's avatar
      Update V8 DEPS. · ecbbbc28
      v8-ci-autoroll-builder authored
      Rolling v8/base/trace_event/common: https://chromium.googlesource.com/chromium/src/base/trace_event/common/+log/ea3ab7b..eb94f1c
      
      Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/d6e2fed..53ad43e
      
      Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b7c1c3f..957c117
      
      Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/6e970e5..39d870e
      
      Rolling v8/third_party/zlib: https://chromium.googlesource.com/chromium/src/third_party/zlib/+log/26211a5..8cd0fc1
      
      TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
      
      Change-Id: Icf10ea4c489ca2eab5f810cfd2788abdf1b02945
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476866Reviewed-by: 's avatarv8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
      Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#70555}
      ecbbbc28
  2. 15 Oct, 2020 17 commits