1. 17 May, 2022 2 commits
  2. 13 May, 2022 1 commit
  3. 06 May, 2022 1 commit
  4. 03 May, 2022 2 commits
  5. 13 Apr, 2022 1 commit
  6. 06 Apr, 2022 1 commit
  7. 30 Mar, 2022 1 commit
    • Jakob Gruber's avatar
      Refactor OptimizationMarker and ConcurrencyMode enums · 57d985a5
      Jakob Gruber authored
      .. with readability and simplicity in mind.
      
      - Rename OptimizationMarker to the (shorter) TieringState. 'Tiering'
        also matches 'TieringManager' terminology.
      - Rename the values:
        kNone -> kNone
        kInOptimizationQueue -> kInProgress
        kCompileFoo_NotConcurrent -> kRequestFoo_Synchronous
        kCompileFoo_Concurrent -> kRequestFoo_Concurrent
      - Likewise rename ConcurrencyMode::kNotConcurrent to kSynchronous.
      - Add predicates to test enum values.
      - Consistent lower case names for accessors on JSFunction and
        FeedbackVector.
      - Instead of having to call HasOptimizationMarker() before using any
        other accessor, simply have optimization_marker() return kNone if
        no feedback vector exists.
      - Drive-by: Enable the Unreachable() in MaybeOptimizeCode()
        unconditionally - this should never happen, there's no reason not
        to protect against this in release builds as well.
      
      Bug: v8:12161
      Change-Id: I67c03e2b7bd0a6b86d0c64f504ad8cb47e9e26ae
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3555774Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79669}
      57d985a5
  8. 25 Mar, 2022 2 commits
  9. 24 Mar, 2022 2 commits
    • Igor Sheludko's avatar
      [runtime] Fix handling of interceptors · 0981e91a
      Igor Sheludko authored
      Bug: chromium:1309225
      Change-Id: Ifd62639a2aa18b633e7cf36632677ee16c977afd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548458Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79613}
      0981e91a
    • Joyee Cheung's avatar
      [ic] fix handling of existing properties in Define{Keyed|Named}OwnIC · 4ee68d81
      Joyee Cheung authored
      - When the property being defined with DefineKeyedOwnIC or
        DefineNamedOwnIC already exists, we should use the slow path to
        check if the operation is allowed in case the property is
        non-configurable or Object.preventExtensions() has been called on
        the property.
      - Since KeyedStoreIC:Store() reuses StoreIC::Store() when the key is a
        name, we should use Runtime::DefineObjectOwnProperty() for
        DefineKeyedOwnIC too.
      - When dealing with public fields, Runtime::DefineObjectOwnProperty()
        should use JSReceiver::CreateDataProperty() instead of
        Object::SetProperty() for the specified semantics. This patch also
        adds JSReceiver::AddPrivateField() for it and StoreIC::Store to
        define private fields without triggering traps or checking
        extensibility.
      - To emit a more specific error message when redefining properties
        on non-extensible objects, Object::AddDataProperty() now also takes
        a EnforceDefineSemantics enum to distinguish between set and define.
      - Drive-by: fix JSReceiver::CheckIfCanDefine() which should check for
        extensibility even if the configurability check passes.
      
      Bug: chromium:1259950, v8:9888
      Change-Id: Ib1bc851ffd4b9c3a0e98cac96dafe743c08ee37e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3517934Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#79603}
      4ee68d81
  10. 14 Mar, 2022 1 commit
  11. 25 Feb, 2022 1 commit
  12. 23 Feb, 2022 1 commit
  13. 18 Feb, 2022 2 commits
    • Shu-yu Guo's avatar
      Plumb Isolate through GetDataProperty · 489527d4
      Shu-yu Guo authored
      Currently the Isolate is gotten off of the object that the operation is
      being performed on. GetDataProperty may end up using a per-Isolate
      lookup cache, which is not threadsafe when the Isolate is shared. Plumb
      the executing, non-shared Isolate through.
      
      Bug: v8:12646, v8:12547
      Change-Id: Ia08ece9a9e8cbd7eba9ea38b01caa511895f5bf4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3475084Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79180}
      489527d4
    • Michael Achenbach's avatar
      Revert "[shared-struct] Prototype JS shared structs" · c1078b5e
      Michael Achenbach authored
      This reverts commit 1025bf26.
      
      Reason for revert: https://crbug.com/v8/12645
      
      Original change's description:
      > [shared-struct] Prototype JS shared structs
      >
      > Unlike the Stage 1 proposal, for simplicity the prototype does not add
      > any new syntax, instead opting for exposing a SharedStructType
      > constructor which takes an array of field names. This type constructor
      > returns constructors for shared structs.
      >
      > Shared structs can be shared across Isolates, are fixed layout, have no
      > prototype, have no .constructor, and can only store primitives and
      > other shared structs.
      >
      > The initial prototype does not have TurboFan support.
      >
      > Bug: v8:12547
      > Change-Id: I23bdd819940b42139692bcdb53d372099b0d4426
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3390643
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79156}
      
      Bug: v8:12547
      Change-Id: I44f2b8bb7487b4d39ba1282585e0b2282501230f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3474676
      Auto-Submit: Michael Achenbach <machenbach@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Owners-Override: Michael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79170}
      c1078b5e
  14. 17 Feb, 2022 2 commits
  15. 16 Feb, 2022 1 commit
  16. 07 Feb, 2022 1 commit
  17. 05 Feb, 2022 3 commits
  18. 27 Jan, 2022 2 commits
  19. 20 Jan, 2022 1 commit
  20. 18 Jan, 2022 2 commits
  21. 17 Jan, 2022 1 commit
  22. 10 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [inspector] Capture stack trace only once for JSError objects. · 765ca6a0
      Benedikt Meurer authored
      When creating a new JSError object (or using the non-standard API
      `Error.captureStackTrace`) V8 would previously capture the "simple stack
      trace" (as FixedArray of CallSiteInfo instances) to be used for the non-
      standard `error.stack` property, and if the inspector was active also
      capture the "detailed stack trace" (as FixedArray of StackFrameInfo
      instances). This turns out to be quite a lot of overhead, both in terms
      of execution time as well as memory pressure, especially since the
      information needed for the inspector is a proper subset of the
      information needed by `error.stack`.
      
      So this CL addresses the above issue by capturing only the "simple stack
      trace" (in the common case) and computing the "detailed stack trace"
      from the "simple stack trace" when on demand. This is accomplished by
      introducing a new ErrorStackData container that is used to store the
      stack trace information on JSErrors when the inspector is active. When
      capturing stack trace for a JSError object while the inspector is
      active, we take the maximum of the program controlled stack trace limit
      and the inspector requested stack trace limit, and memorize the program
      controlled stack trace limit for later formatting (to ensure that the
      presence of the inspector is not observable by the program).
      
      On the `standalone.js` benchmark from crbug.com/1283162 (with the
      default max call stack size of 200) we reduce execution time by around
      16% compared to ToT. And compared to V8 9.9.4 (the version prior to the
      regression in crbug.com/1280831), we are 6% faster now.
      
      Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
      Bug: chromium:1280831, chromium:1278650, chromium:1258599
      Bug: chromium:1280803, chromium:1280832, chromium:1280818
      Fixed: chromium:1283162
      Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78542}
      765ca6a0
  23. 14 Dec, 2021 1 commit
  24. 06 Dec, 2021 2 commits
  25. 30 Nov, 2021 2 commits
  26. 26 Nov, 2021 1 commit
  27. 18 Nov, 2021 1 commit
  28. 15 Nov, 2021 1 commit