1. 24 Feb, 2021 4 commits
  2. 23 Feb, 2021 2 commits
  3. 22 Feb, 2021 2 commits
    • Omer Katz's avatar
      cppgc: Run prefinalizers in termination GC · 94387f67
      Omer Katz authored
      Bug: chromium:1056170
      Change-Id: Ifb5a2cfa5f3fd2fbfecb84b1bf8f3dc464a823ef
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2711264Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72901}
      94387f67
    • Omer Katz's avatar
      cppgc: Fix termination GCs · 7a22cf7a
      Omer Katz authored
      Whenever we destroy an object that contains a
      (Weak)(CrossThread)Persistent, we call the Persistent's dtor which frees
      the relevant PersistentNode. To get the PersistentRegion for the node,
      we get the value, then get the the relevant page which holds a reference
      to the heap which holds the regions.
      
      During a termination GC there is no marking and no weak callback
      processing. That means that, when destroying a Persistent, the page on
      which the object referenced by the Persistent resides may have already
      been swept and destroyed. Then when we try to get the page we cleared or
      unallocated memory and crash.
      This issue presented as a sweeper crash in the web tests and
      content_browsertests.
      
      This issue affects only Weak(CrossThread)Persistent since the region for
      their strong counterparts are already cleared at the start of a
      termination GC.
      This is not an issue in the Blink impl because (1) Blink finds the
      elevant regions through ThreadState without going through pages, and
      (2) Blink runs a  full GC on termination that includes executing weak
      callbacks.
      
      Alternatively we could trace the Weak(CrossThread)Persistent region
      which will run the weakness callbacks and clear all WeakPersistents.
      The cost and outcome is equivalent.
      
      Bug: chromium:1056170
      Change-Id: I3db5b01424500eb695f9876247ef0c787d0d9ef2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2708645
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72897}
      7a22cf7a
  4. 19 Feb, 2021 4 commits
    • Michael Lippautz's avatar
      cppgc-js: Use atomic sweeping for forced GCs · 240ed3c3
      Michael Lippautz authored
      Forced GCs are used in testing configurations and under memory
      pressure. Use atomic sweeping for C++ in those scenarios as testing
      GCs require that destructors are immediately invoked after the GC
      call.
      
      Bug: chromium:1056170
      Change-Id: I03c13fa7a30cf74076807834c5e6d0c1fe52bb87
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704543
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72873}
      240ed3c3
    • Mike Stanton's avatar
      [TurboFan] Mark Code object as never serialized · be699045
      Mike Stanton authored
      Code objects are exposed through JSFunction and SharedFunctionInfo.
      If they are builtins, we don't have to worry about background threads
      seeing partially initialized code objects. If they are optimized code
      objects, we may. Background threads read the code fields with
      AcquireLoad semantics. The fields are set on the main thread with
      ReleaseStore semantics when appropriate.
      
      Special care is taken when setting an optimized code object in a closure
      in the interpreter entry stub. Since the MacroAssembler doesn't support
      ReleaseStore semantics, this CL ensures that the optimized code object
      is stored with those semantics in the feedback vector, where the
      interpreter entry stub finds it.
      
      Bug: v8:7790
      Change-Id: I41ecedfe0e9d1ad5091cbe9a97f66c66ca9e07dd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676633
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72869}
      be699045
    • Frank Emrich's avatar
      [dict-proto] C++ implementation of SwissNameDictionary, pt. 3 · a2c31f74
      Frank Emrich authored
      This is a reland of
      https://chromium-review.googlesource.com/c/v8/v8/+/2688058
      
      This CL is part of a series that adds the C++ implementation of
      SwissNameDictionary, a deterministic property backing store based on
      Swiss Tables.
      
      This CL adds the initialization code, factory functions and a
      canonical SwissNameDictionary plus all helpers required for that.
      
      Bug: v8:11388
      Change-Id: I9cf66a3fa755288f7730f55abfb6e6cea82f6b03
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2703653
      Commit-Queue: Frank Emrich <emrich@google.com>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72857}
      a2c31f74
    • Seth Brenith's avatar
      Revert "Remove 'length' field from ScopeInfo" · 6c922e39
      Seth Brenith authored
      This reverts commit f731e13f.
      
      Reason for revert: perf regressions, chromium:1179757
      
      Original change's description:
      > Remove 'length' field from ScopeInfo
      >
      > ScopeInfo has a vestigial 'length' field from when it used to be a
      > FixedArray. This change removes that field, which saves some memory.
      >
      > More specifically:
      >
      > - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
      >   supplied the 'length' field.
      > - Privatize the FixedArray-style functions that provide access to
      >   ScopeInfo fields by index, and move them from scope-info-inl.h to
      >   scope-info.cc. Those functions are still used pretty heavily during
      >   initialization (ScopeInfo::Create, etc.), but at least we can avoid
      >   presenting them to the rest of the world.
      > - Change FactoryBase::NewScopeInfo to allocate the updated object shape.
      >   It maintains the existing behavior of filling the newly-allocated
      >   object with undefined, even though that's not a valid ScopeInfo and
      >   further initialization is required.
      > - Move part of AccessorAssembler::ScriptContextTableLookup into a new
      >   Torque macro, because it used to rely on casting ScopeInfo to
      >   FixedArrayBase.
      > - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
      >   arrays. I think it makes more sense to list them under "(system)" in
      >   the dev tools, like most other V8 internal types.
      >
      > Bug: v8:8952
      > Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72830}
      
      Bug: v8:8952
      Change-Id: I00a69da79e5ac6aaae4436a41ce773ae014cc775
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706086
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Auto-Submit: Seth Brenith <seth.brenith@microsoft.com>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72855}
      6c922e39
  5. 18 Feb, 2021 2 commits
  6. 17 Feb, 2021 5 commits
    • Omer Katz's avatar
      cppgc: Implement process-global state accessors. · c174643b
      Omer Katz authored
      Process global accessors for total physical size and used size are
      needed for blink. These are implemented via an allocation observer that
      atomically updates static counters.
      
      The public api only provides getters for the counters. An internal class
      is in charge of updating the counters as needed. A similar split is also
      applied to IsAnyIncrementalOrConcurrentMarking().
      
      Drive-by: ProcessHeap is merged into cppgc::internal::WriteBarrier.
      
      Bug: chromium:1056170
      Change-Id: Iaedebd1ac9d49238ce6bdd52ffa5d1ef4d28203d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695394
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72832}
      c174643b
    • Omer Katz's avatar
      cppgc: Fix IsMarking checks. · 81078e2b
      Omer Katz authored
      IsMarking returns true as long as a marker exists. That means IsMarking
      is true during weak processing as well.
      ActiveScriptWrappableManager in blink uses a weak callback that updates
      a HeapVector and thus can trigger a write barrier during the atomic
      pause (which violates a DCHECK in the barrier).
      
      Bug: chromium:1056170
      Change-Id: I6304b38da9751320836a5e2407e8c7d529367bad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2700676Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72831}
      81078e2b
    • Seth Brenith's avatar
      Remove 'length' field from ScopeInfo · f731e13f
      Seth Brenith authored
      ScopeInfo has a vestigial 'length' field from when it used to be a
      FixedArray. This change removes that field, which saves some memory.
      
      More specifically:
      
      - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
        supplied the 'length' field.
      - Privatize the FixedArray-style functions that provide access to
        ScopeInfo fields by index, and move them from scope-info-inl.h to
        scope-info.cc. Those functions are still used pretty heavily during
        initialization (ScopeInfo::Create, etc.), but at least we can avoid
        presenting them to the rest of the world.
      - Change FactoryBase::NewScopeInfo to allocate the updated object shape.
        It maintains the existing behavior of filling the newly-allocated
        object with undefined, even though that's not a valid ScopeInfo and
        further initialization is required.
      - Move part of AccessorAssembler::ScriptContextTableLookup into a new
        Torque macro, because it used to rely on casting ScopeInfo to
        FixedArrayBase.
      - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
        arrays. I think it makes more sense to list them under "(system)" in
        the dev tools, like most other V8 internal types.
      
      Bug: v8:8952
      Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72830}
      f731e13f
    • Bill Budge's avatar
      Revert "[dict-proto] C++ implementation of SwissNameDictionary, pt. 3" · 1ff071c1
      Bill Budge authored
      This reverts commit 2f8a7561.
      
      Reason for revert: Speculative revert, lots of segfaults on Arm:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/17781
      
      Original change's description:
      > [dict-proto] C++ implementation of SwissNameDictionary, pt. 3
      >
      > This CL is part of a series that adds the C++ implementation of
      > SwissNameDictionary, a deterministic property backing store based on
      > Swiss Tables.
      >
      > This CL adds the initialization code, factory functions and a
      > canonical SwissNameDictionary plus all helpers required for that.
      >
      > Bug: v8:11388
      > Change-Id: I6bb92740afefc7d05433cfa62023e6da5e8213c7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688058
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Commit-Queue: Frank Emrich <emrich@google.com>
      > Cr-Commit-Position: refs/heads/master@{#72824}
      
      Bug: v8:11388
      Change-Id: Ia5dae584b0fb452b12c5d64ee63ffa418c83f91b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698758
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72829}
      1ff071c1
    • Frank Emrich's avatar
      [dict-proto] C++ implementation of SwissNameDictionary, pt. 3 · 2f8a7561
      Frank Emrich authored
      This CL is part of a series that adds the C++ implementation of
      SwissNameDictionary, a deterministic property backing store based on
      Swiss Tables.
      
      This CL adds the initialization code, factory functions and a
      canonical SwissNameDictionary plus all helpers required for that.
      
      Bug: v8:11388
      Change-Id: I6bb92740afefc7d05433cfa62023e6da5e8213c7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688058Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Frank Emrich <emrich@google.com>
      Cr-Commit-Position: refs/heads/master@{#72824}
      2f8a7561
  7. 16 Feb, 2021 3 commits
  8. 15 Feb, 2021 3 commits
  9. 12 Feb, 2021 7 commits
    • Omer Katz's avatar
      cppgc: Fix ObjectSizeTrait · b804a54b
      Omer Katz authored
      HeapObjectHeader::GetSize returns object size including
      HeapObjectHeader. This is find for our internal usages since we want to
      know the actual size consumed by the object.
      ObjectSizeTrait should report object size for external users for which
      the HeapObjectHeader should be invisible. The sizes returned by the
      trait should exclude the header.
      
      Bug: chromium:1056170
      Change-Id: I75111b9a3d0d27d0a39df4abdacaa84f1cee3a5a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692689
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Auto-Submit: Omer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72723}
      b804a54b
    • Victor Gomes's avatar
      [cleanup] Create Factory::NewBaselineData · 02e477e3
      Victor Gomes authored
      Change-Id: Ia115a8dfd35c935fa4356dd32dcd2e035574f7d1
      Bug: v8:11429
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692566Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72711}
      02e477e3
    • Georg Neis's avatar
      Reland "[compiler] Directly read PropertyCells" · cf7cba8d
      Georg Neis authored
      This reverts commit 87df0b7e (thus
      relands 42cd9eb7), with fixes for
      the discovered issues.
      
      Original change's description:
      > Revert "[compiler] Directly read PropertyCells"
      >
      > This reverts commit 42cd9eb7.
      >
      > Reason for revert: Clusterfuzz issues, e.g.
      > https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
      >
      > Original change's description:
      > > [compiler] Directly read PropertyCells
      > >
      > > Main changes:
      > >
      > > - Introduce a new broker data kind kBackgroundSerialized for objects
      > >   that can be serialized in the background (when direct reads are on).
      > >   (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
      > >   in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
      > > - Make PropertyCell use that new kind.
      > > - Introduce a bottleneck in runtime code for changes to PropertyCells
      > >   and make sure that a certain protocol is followed that allows
      > >   concurrent reads from the background thread.
      > > - Improve interface of PropertyCell in various ways.
      > >
      > > Bug: v8:7790
      > > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Commit-Queue: Georg Neis <neis@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#72586}
      >
      > TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
      >
      > Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
      > Bug: v8:7790
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72619}
      
      Bug: v8:7790, chromium:1176509, chromium:1176318, chromium:1176504
      Change-Id: Icaf285912bb948432a4a2d599cd174f6a5aa296e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685166Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72697}
      cf7cba8d
    • Leszek Swirski's avatar
      [sparkplug] Change Sparkplug to Baseline · c913ef3a
      Leszek Swirski authored
      Currently we sometimes refer to baseline code or the baseline compiler
      by its codename (Sparkplug). The codename is fun, but we should be
      consistent and call things by one name or the other. Following the
      pattern of Ignition stuff being called "interpreter", we call Sparkplug
      "baseline", and leave the codename only in flags and variants.
      
      Bug: v8:11420
      Change-Id: I432e5629518be7c7ad38b6acff024c91d4cfd6d3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692186
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72696}
      c913ef3a
    • 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
    • Leszek Swirski's avatar
      [sparkplug] Upstream Sparkplug · c053419e
      Leszek Swirski authored
      Sparkplug is a new baseline, non-optimising second-tier compiler,
      designed to fit in the compiler trade-off space between Ignition and
      TurboProp/TurboFan.
      
      Design doc:
      https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A/edit?usp=sharing
      
      Bug: v8:11420
      Change-Id: Ideb7270db3d6548eedd8337a3f596eb6f8fea6b1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667514
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72686}
      c053419e
  10. 11 Feb, 2021 7 commits
  11. 10 Feb, 2021 1 commit