1. 12 Feb, 2021 3 commits
    • Benedikt Meurer's avatar
      [inspector][stack-traces] Remove support for "displayName". · a9b6f3f7
      Benedikt Meurer authored
      As outlined in the design document linked below, we're removing the
      support for the non-standard Function.displayName property for the
      purpose of Error.stack and DevTools Inspector stack traces. The
      motivation here is that the negative lookup is costly, and we have
      Function.name as a standard alternative (configurable since ES6 for
      exactly this reason).
      
      I dediced to go with JSFunction::GetDebugName(), since
      JSFunction::GetName() was confusing in that it'd only get the "name"
      property's value if it's a data property, but not with accessors.
      JSFunction::GetDebugName() makes it clear that this is really a debug
      helper function and might not give you the "name" property value.
      
      Doc: https://bit.ly/devtools-function-displayName-removal
      Bug: v8:8742, chromium:1177685, chromium:1077657, chromium:17356
      Change-Id: I7717585cbace626174b2f2ed2a4f68f75429eca1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692189
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72715}
      a9b6f3f7
    • Benedikt Meurer's avatar
      [stack-traces] Simplify and speedup stack trace collection. · eed0d27c
      Benedikt Meurer authored
      Following up on https://crrev.com/c/2689185, this CL significantly
      simplifies the whole implementation of the stack trace capturing.
      
      Before this CL, capturing any stack trace (for the purpose of the API or
      Error.stack) would roughly work like this:
      
        1. The CaptureStackTrace() function uses the StackFrameIterator to
           walk the system stack. For each native frame it uses the
           FrameSummary abstraction to get all (including potentially inlined)
           frames. For each of those it appends a record consisting of six
           elements to a FrameArray (this holds pointers to the actual
           closures and receivers).
        2. Afterwards the FrameArray is shrinked to the required size, and a
           new FixedArray is allocated, and initialized with new
           StackTraceFrame objects where each holds a reference to the
           FrameArray, the index of the frame, and an initially uninitialized
           StackFrameInfo reference. This new FixedArray is then returned from
           CaptureStackTrace() and either stored on a message object or
           provided to the API as v8::StackTrace.
      
      The new approach removes a lot of the machinery in between and directly
      creates a FixedArray of StackFrameInfo objects in CaptureStackTrace().
      These StackFrameInfo objects are directly exposed as v8::StackFrame on
      the public API, and they hold the six fields that were previously stored
      flat in the FrameArray. This not only avoids a lot of copying around of
      data and creation of temporary objects and handles, but most importantly
      unifies and simplifies the stack frame function inside StackFrameInfo,
      so you no longer need to wonder which function / object might be
      responsible for a certain API.
      
      There's still a lot of room for improvement. In particular we currently
      don't cache the source position for a given StackFrameInfo (or
      globally), but rather recompute it every time. This is still very fast,
      significantly faster than the previous approach.
      
      There are some notable (potentially user visible) changes:
      
        - The CallSite#GetPosition() method now consistently returns the
          Wasm module relative bytecode offset for all Wasm frames (previously
          it'd return the function relative bytecode offset for non-asm.js
          Wasm frames).
        - The column and line numbers returned from StackFrameInfo methods are
          consistently 1-based now, instead of sometimes being 0-based (Wasm)
          and sometimes being 1-based (JS and asm.js Wasm). The only
          potentially noticable difference is that for
          CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but
          that was wrong and useless anyways.
        - CallSite#GetThis() would sometimes return the_hole, another bug
          flushed out by this CL.
      
      The CL also contains some other not noteworthy drive-by-cleanups.
      
      Fixed: chromium:1057211
      Bug: chromium:1077657, chromium:1069425, v8:8742
      Bug: chromium:1127391, chromium:1098530, chromium:981541
      Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72694}
      eed0d27c
    • Santiago Aboy Solanes's avatar
      [heap] Simplify mark-compact after double field unboxing deletion · 18925744
      Santiago Aboy Solanes authored
      Bug: v8:11422
      Change-Id: I106b2226d531d7a868ac9344cce8c965250316e1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690589Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72692}
      18925744
  2. 29 Jan, 2021 1 commit
  3. 28 Jan, 2021 3 commits
  4. 26 Jan, 2021 2 commits
    • Benedikt Meurer's avatar
      [inspector] Fix crash due to misuse of embedder fields. · 7e2f1108
      Benedikt Meurer authored
      The contract between V8 and Blink is that embedder fields belong to
      Blink, at least when the object has two or more of them. Now we had 2-3
      embedder fields used by the debug proxies and that was confusing Blink,
      since it expects the first slot to hold an aligned pointer in that case
      and we had a HeapObject reference stored there.
      
      This is a quickfix, which avoids internal fields completely for the
      context extension proxy (using interceptors on the prototype instead)
      and changes the named proxies to store the name table under a private
      symbol instead of using a second internal field.
      
      A proper but way more involved fix is to introduce a proper instance
      type here and use space in the header instead of misusing embedder
      fields.
      
      Fixed: chromium:1170283
      Bug: chromium:1159402
      Change-Id: I6c4bbe2fe88fef29a6b9946708588245efbbe72b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649033
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72323}
      7e2f1108
    • Shu-yu Guo's avatar
      [regexp] Implement the /d flag for RegExp indices · 81e7e2f4
      Shu-yu Guo authored
      This CL implements the upcoming spec change:
      https://github.com/tc39/proposal-regexp-match-indices/pull/49
      
      A new JSRegExpResultWithIndices subclass is introduced with a separate map and
      an extra slot for storing the indices. If /d is passed, exec() constructs a
      JSRegExpResultWithIndices and eagerly builds indices.
      
      The existing re-execution logic is removed.
      
      Bug: v8:9548
      Change-Id: Ic11853e7521017af5e8bd583c7b82bb672821132
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616873
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72306}
      81e7e2f4
  5. 19 Jan, 2021 2 commits
  6. 18 Jan, 2021 1 commit
  7. 14 Jan, 2021 1 commit
  8. 08 Jan, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Implement Debug Proxy API via Interceptors. · c27c167c
      Benedikt Meurer authored
      Previously the Debug Proxy API that's exposed on Wasm frames by
      Runtime.evaluateOnCallFrame() was implemented via actual JSProxy
      instances. That means that all entities such as "memories", "tables",
      "stack", "globals", etc. were JSProxy instances with "get" and "has"
      traps. But that has a couple of down-sides:
      
      1. In DevTools front-end, the proxies are shown as JSProxy, which is not
         very useful to developers, since they cannot interact with them nor
         can they inspect their contents. And the object preview also only
         shows "Proxy {}" for them.
      2. The performance doesn't scale well, which becomes a painful
         bottleneck with larger Wasm modules that contain hundreds of
         thousands of functions or globals.
      3. We cannot use the JSProxy instances in the Scope view (for the
         reasons outlined in 1.) and hence we have different logic to provide
         Scope values than values in the rest of DevTools, which led to subtle
         but annoying bugs and inconsistencies.
      
      This also changes the "locals" implementation by querying the values
      ahead of time, similar to the object exposed to the Scope view, instead
      of on-demand, since the "locals" object might survive the current
      debugger pause and peeking into the stack afterwards would read invalid
      memory (and might even be a security issue). For being able to change
      locals we need to look into a similar solution as what we have for
      JavaScript locals already. The expression stack already works this way.
      
      For performance reasons (especially scaling to huge, realistic Wasm
      modules), we cache the per-instance proxies ("functions", "memories",
      "tables" and "globals") on the WasmInstanceObject and reuse them (which
      is safe since they have a `null` prototype and are non-extensible), and
      we also cache the proxy maps (with the interceptors) on the
      JSGlobalObject per native context.
      
      Doc: http://bit.ly/devtools-wasm-entities
      Bug: chromium:1127914, chromium:1159402, chromium:1071432, chromium:1164241
      Change-Id: I6191035fdfd887835ae533fcdaabb5bbc8e661ae
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606058
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71981}
      c27c167c
  9. 16 Dec, 2020 2 commits
    • Dominik Inführ's avatar
      [heap] Move completion of sweeping before actual GC · 9aaf874a
      Dominik Inführ authored
      This CL completes sweeping in Heap::PerformGarbageCollection before
      invoking the actual collection. Collection code can now assume that
      sweeping was already finished.
      
      This helps with emitting the right epoch for sweeping and avoids a
      data-race when updating the epoch while sweeping tasks are still running.
      
      Bug: chromium:1154636
      Change-Id: Ic9c4ac49568199d0ea48f17eea132079defe74a5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2573478
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71794}
      9aaf874a
    • Dominik Inführ's avatar
      Reland^3 [heap] Add epoch to GC tracing events · 893f32fe
      Dominik Inführ authored
      This is a reland of b614cd78
      
      Original change's description:
      > Reland "Reland "[heap] Add epoch to GC tracing events""
      >
      > This is a reland of 3238162d
      >
      > No changes since the last reland.
      >
      > Original change's description:
      > > Reland "[heap] Add epoch to GC tracing events"
      > >
      > > This is a reland of be52501d
      > >
      > > 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: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71777}
      893f32fe
  10. 04 Dec, 2020 2 commits
    • Sathya Gunasekaran's avatar
      Revert "Reland "Reland "[heap] Add epoch to GC tracing events""" · fb37749a
      Sathya Gunasekaran authored
      This reverts commit b614cd78.
      
      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 3238162d
      >
      > No changes since the last reland.
      >
      > Original change's description:
      > > Reland "[heap] Add epoch to GC tracing events"
      > >
      > > This is a reland of be52501d
      > >
      > > 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/+/2574002Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71610}
      fb37749a
    • Dominik Inführ's avatar
      Reland "Reland "[heap] Add epoch to GC tracing events"" · b614cd78
      Dominik Inführ authored
      This is a reland of 3238162d
      
      No changes since the last reland.
      
      Original change's description:
      > Reland "[heap] Add epoch to GC tracing events"
      >
      > This is a reland of be52501d
      >
      > 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/+/2571122Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71609}
      b614cd78
  11. 03 Dec, 2020 1 commit
  12. 02 Dec, 2020 2 commits
    • Maya Lekova's avatar
      Revert "Reland "[heap] Add epoch to GC tracing events"" · 78e9a3a7
      Maya Lekova authored
      This reverts commit 3238162d.
      
      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 be52501d
      >
      > 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/+/2569764Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71569}
      78e9a3a7
    • Dominik Inführ's avatar
      Reland "[heap] Add epoch to GC tracing events" · 3238162d
      Dominik Inführ authored
      This is a reland of be52501d
      
      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: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71567}
      3238162d
  13. 01 Dec, 2020 2 commits
  14. 30 Nov, 2020 1 commit
  15. 25 Nov, 2020 1 commit
  16. 24 Nov, 2020 1 commit
  17. 30 Oct, 2020 1 commit
    • Martin Bidlingmaier's avatar
      [regexp] Add 'l' flag to force experimental engine · 5720d205
      Martin Bidlingmaier authored
      This commit adds the 'l' (linear) RegExp flag (as in e.g. /asdf|123/l)
      that forces execution in linear time.  These regexps are handled by the
      experimental engine.  If the experimental engine cannot handle the
      pattern, an exception is thrown on creation of the regexp.
      
      The commit also adds a new global V8 flag and changes an existing one:
      * --enable-experimental-engine, which turns on recognition of the RegExp
        'l' flag.  Previously this flag also caused all supported regexps to
        be executed by the experimental engine; this is not the case anymore.
      * --default-to-experimental-regexp-engine takes over the previous
        semantics of --enable-experimental-regexp-engine:  We execute all
        supported regexps with the experimental engine.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:10765
      Change-Id: I5622a89b19404105e8be280d454e9fdd63c003b3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461244Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Martin Bidlingmaier <mbid@google.com>
      Cr-Commit-Position: refs/heads/master@{#70892}
      5720d205
  18. 29 Oct, 2020 1 commit
    • Dominik Inführ's avatar
      [heap] Merge ArrayBufferExtension lists sooner · deda7cd0
      Dominik Inführ authored
      Merge the list of concurrently swept ArrayBufferExtensions sooner back
      to the main thread. When appending a new ArrayBufferExtension check
      whether the concurrent sweeping was already finished and merge the lists
      if it is.
      
      In order to reduce the number of GCs in the linked test case, reset
      young_bytes_ and old_bytes_ to 0 while sweeping the
      ArrayBufferExtensions. Surviving extensions will be accounted again
      when merging lists.
      
      As a drive-by change remove scavenge.process_array_buffers from
      GCTracer. GCTracer also printed the wrong value for fast_promote.
      
      Bug: v8:11044
      Change-Id: I8a772df895c43a69493015f42336c6f33fe52056
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505764Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70880}
      deda7cd0
  19. 27 Oct, 2020 1 commit
    • Mike Stanton's avatar
      [TurboFan] Provide concurrent access to feedback vector · 2288b1f6
      Mike Stanton authored
      This CL provides synchronized get/set to feedback vector slots.
      The FeedbackNexus is set up to use order preserving reads when used
      on the background thread, and a lock to ensure coherent read
      of information for ICKinds with two slots. The main thread takes
      the lock on sets.
      
      This test provides patterns to be followed by concurrent TurboFan.
      
      We don't yet access the FeedbackVector on the background thread.
      This CL only makes it safe to do so. The next step will come when
      the optimizing compiler begins to query the the vector from the
      background thread. Currently, with --concurrent-inlining turned on
      this is done in bytecode serialization on the main thread. Without
      concurrent inlining, it's also done on the main thread, in both
      cases using the FeedbackNexus.
      
      Bug: v8:7790
      Change-Id: I49d8b8031190f91a0da1c24f375b6b6d8a9fe038
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2276210
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70797}
      2288b1f6
  20. 22 Oct, 2020 1 commit
  21. 15 Oct, 2020 1 commit
  22. 13 Aug, 2020 1 commit
  23. 03 Aug, 2020 1 commit
  24. 30 Jul, 2020 1 commit
  25. 27 Jul, 2020 2 commits
  26. 16 Jul, 2020 1 commit
  27. 27 May, 2020 1 commit
  28. 12 May, 2020 1 commit
  29. 21 Apr, 2020 1 commit