1. 27 Apr, 2021 3 commits
  2. 21 Apr, 2021 2 commits
  3. 20 Apr, 2021 3 commits
    • Stephen Belanger's avatar
      Reland "[api] JSFunction PromiseHook for v8::Context" · c0fceaa0
      Stephen Belanger authored
      This is a reland of d5457f5f
      after a speculative revert.
      
      Additionally it fixes an issue with throwing promise hooks.
      
      Original change's description:
      > [api] JSFunction PromiseHook for v8::Context
      >
      > This will enable Node.js to get much better performance from async_hooks
      > as currently PromiseHook delegates to C++ for the hook function and then
      > Node.js delegates it right back to JavaScript, introducing several
      > unnecessary barrier hops in code that gets called very, very frequently
      > in modern, promise-heavy applications.
      >
      > This API mirrors the form of the original C++ function based PromiseHook
      > API, however it is intentionally separate to allow it to use JSFunctions
      > triggered within generated code to, as much as possible, avoid entering
      > runtime functions entirely.
      >
      > Because PromiseHook has internal use also, beyond just the Node.js use,
      > I have opted to leave the existing API intact and keep this separate to
      > avoid conflicting with any possible behaviour expectations of other API
      > users.
      >
      > The design ideas for this new API stemmed from discussion with some V8
      > team members at a previous Node.js Diagnostics Summit hosted by Google
      > in Munich, and the relevant documentation of the discussion can be found
      > here: https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit#heading=h.w1bavzz80l1e
      >
      > A summary of the reasons for why this new design is important can be
      > found here: https://docs.google.com/document/d/1vtgoT4_kjgOr-Bl605HR2T6_SC-C8uWzYaOPDK5pmRo/edit?usp=sharing
      >
      > Bug: v8:11025
      > Change-Id: I0b403b00c37d3020b5af07b654b860659d3a7697
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759188
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Anton Bikineev <bikineev@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73858}
      
      Bug: v8:11025
      Bug: chromium:1197475
      Change-Id: I73a71e97d9c3dff89a2b092c3fe4adff81ede8ef
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2823917Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74071}
      c0fceaa0
    • Maya Lekova's avatar
      Reland "[fastcall] Add support for leaf interface type checks" · 5540fbfc
      Maya Lekova authored
      This is a reland of 6124a534
      
      It fixes a UAF issue in the d8 test by moving the test API object
      constructor to PerIsolateData. It also fixes a crash in Chromium
      caused by current usage of v8::ApiObject, which should be migrated
      to v8::Value*.
      
      Original change's description:
      > [fastcall] Add support for leaf interface type checks
      >
      > This CL adds an IsTemplateForApiObject method to FunctionTemplate
      > allowing the embedder to check whether a given API object was
      > instantiated by this template without including parent templates
      > in the search. It also replaces the v8::ApiObject in the fast API
      > with a raw v8::Value pointer to allow use of standard C++ casts.
      >
      > Bug: chromium:1052746
      > Change-Id: I0812ec8b4daaa5f5005aabf10b63e1e84e0b8f03
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595310
      > Commit-Queue: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73999}
      
      Bug: chromium:1052746, chromium:1199900
      Change-Id: I4b7f0c9e9152919dde4a1d0c48fbf5ac8c5b13d8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835711Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74064}
      5540fbfc
    • Sathya Gunasekaran's avatar
      Reland "[ic] Add a new MegaDOM IC" · fbd114bd
      Sathya Gunasekaran authored
      This is a reland of c83c9590
      
      Changes since revert: nothing, issue was crbug.com/v8/11666
      
      Original change's description:
      > [ic] Add a new MegaDOM IC
      >
      > This patch implements the MegaDOM IC setup and access. A new MegaDOM
      > IC state indicates that we've seen only DOM accessors at this access
      > site.
      >
      > This CL only adds support for DOM getters in LoadIC, other kinds of
      > access will be added in follow on CLs.
      >
      > Still remaining TODO before shipping:
      > 1. Have a mechanism to invalidate the protector
      > 2. Have a mechanism to find the accessors that aren't overloaded
      > 3. Use a new builtin to miss to runtime on access check failure
      >
      > Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2
      > Bug: v8:11321
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73733}
      
      Bug: v8:11321
      Change-Id: I2bec54465542b5b40c42adb6eb12b6ce72cce5bd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794439Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74056}
      fbd114bd
  4. 16 Apr, 2021 4 commits
  5. 14 Apr, 2021 2 commits
  6. 13 Apr, 2021 1 commit
  7. 12 Apr, 2021 2 commits
  8. 08 Apr, 2021 4 commits
  9. 07 Apr, 2021 3 commits
  10. 06 Apr, 2021 2 commits
  11. 01 Apr, 2021 1 commit
    • Sara Tang's avatar
      [diagnostics] Enable ETW stack-walking events build flag · f0061332
      Sara Tang authored
      Feedback from Microsoft partners indicates that it would be beneficial
      to enable ETW stack-walking events by default.
      
      This is difficult, because the --interpreted-frames-native-stack flag
      comes with a significant perf degradation. Ideally, we would turn
      this flag on dynamically, only when a ETW recorder is actively
      triggering the provider. Unfortunately, the flag in its current state
      cannot be enabled dynamically.
      
      In light of this, we have decided to only flip the build flag.
      
      Bug: v8:11043
      Change-Id: Id883b9bcd635b41139450ab2d5c92511422525a3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773792Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Sara Tang <sartang@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#73784}
      f0061332
  12. 31 Mar, 2021 2 commits
    • Maya Lekova's avatar
      Revert "[ic] Add a new MegaDOM IC" · 3f8aa89e
      Maya Lekova authored
      This reverts commit c83c9590.
      
      Reason for revert: Speculatively reverting for a failure on Arm GC stress bot - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Arm%20GC%20Stress/b8851256837192083520/overview
      
      Original change's description:
      > [ic] Add a new MegaDOM IC
      >
      > This patch implements the MegaDOM IC setup and access. A new MegaDOM
      > IC state indicates that we've seen only DOM accessors at this access
      > site.
      >
      > This CL only adds support for DOM getters in LoadIC, other kinds of
      > access will be added in follow on CLs.
      >
      > Still remaining TODO before shipping:
      > 1. Have a mechanism to invalidate the protector
      > 2. Have a mechanism to find the accessors that aren't overloaded
      > 3. Use a new builtin to miss to runtime on access check failure
      >
      > Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2
      > Bug: v8:11321
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73733}
      
      Bug: v8:11321
      Change-Id: Ib6a55796f2a3c345d4923f9eaa215a6ff55ed15b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794437
      Auto-Submit: Maya Lekova <mslekova@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#73734}
      3f8aa89e
    • Sathya Gunasekaran's avatar
      [ic] Add a new MegaDOM IC · c83c9590
      Sathya Gunasekaran authored
      This patch implements the MegaDOM IC setup and access. A new MegaDOM
      IC state indicates that we've seen only DOM accessors at this access
      site.
      
      This CL only adds support for DOM getters in LoadIC, other kinds of
      access will be added in follow on CLs.
      
      Still remaining TODO before shipping:
      1. Have a mechanism to invalidate the protector
      2. Have a mechanism to find the accessors that aren't overloaded
      3. Use a new builtin to miss to runtime on access check failure
      
      Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2
      Bug: v8:11321
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73733}
      c83c9590
  13. 25 Mar, 2021 2 commits
  14. 23 Mar, 2021 2 commits
  15. 17 Mar, 2021 1 commit
  16. 16 Mar, 2021 3 commits
  17. 15 Mar, 2021 2 commits
  18. 12 Mar, 2021 1 commit