1. 07 Jul, 2021 1 commit
  2. 23 Jun, 2021 2 commits
  3. 14 Jun, 2021 1 commit
  4. 09 Jun, 2021 1 commit
  5. 08 Jun, 2021 1 commit
    • Daniel Bevenius's avatar
      Add TryGetCurrent() method to v8::Isolate · ca05c5a2
      Daniel Bevenius authored
      This commit adds a TryGetCurrent() method to the v8::Isolate class.
      
      The motivation for adding this method this is that in Node.js we've run
      into situations where we need to check if there is a current
      Isolate and we are using GetCurrent() for this. The issue is that for a
      debug build of Node.js, the debug check in GetCurrent() will cause a
      failure.
      
      The suggestion in this changeset is to allow getting the current
      Isolate, or null if one does not exist, without any checks.
      
      Change-Id: I01676e4bcdbe86da0496f5df1982d14eb1c9ebf8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910630Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75004}
      ca05c5a2
  6. 01 Jun, 2021 1 commit
  7. 21 May, 2021 1 commit
  8. 18 May, 2021 1 commit
  9. 17 May, 2021 1 commit
  10. 12 May, 2021 1 commit
  11. 10 May, 2021 1 commit
  12. 07 May, 2021 1 commit
    • arthursonzogni's avatar
      (reland) [api] Add API callback setter for the SAB origin trial · 22f124ce
      arthursonzogni authored
      This reland patch:
      https://chromium-review.googlesource.com/c/v8/v8/+/2867473
      (See patchset 1)
      
      The problem was blink injecting interceptor into the window object. It
      observes "observation" and "mutations" on this object. When it happens
      to the initial empty document, the IPC DidAccessInitialDocument() is
      sent and modify the state of the browser process. Causing two tests to
      fail.
      
      The diff (See patchset 1..2) includes:
      1. Use JSObject::HasRealNamedProperty instead of JsObject::HasProperty.
         This skips the interceptor and do not walk the prototype chain.
      2. Invert JSObject::HasRealNamedProperty() with
         IsSharedArrayBufferConstructorEnabled(), just in case. This avoid
         observing the object when not needed.
      
      Original patch description:
      ---
      This change makes it possible to enable SharedArrayBuffer per Context,
      controlling whether it should be enabled or not with a callback. The
      previous implementation of the reverse origin trial for
      SharedArrayBuffer was broken, since the feature could only be enabled
      globally per process, and only if the feature flag is set early enough
      in the v8 initialization. This does not play well with how origin
      trials work.
      
      The implementation is similar to the callbacks that already exist for
      the origin trials for WebAssembly simd and exceptions.
      
      SharedArrayBuffer is still controlled by the flag
      harmony_sharedarraybuffer. If that flag is disabled, then
      SharedArrayBuffer is disabled unconditionally. On top of that, this CL
      introduces a new flag for enabling SharedArrayBuffer per context. If
      that flag is set, a callback is used to determine whether
      SharedArrayBuffer should be enabled.
      
      Note that this only controls whether the SharedArrayBuffer constructor
      should be exposed on the global object or not. It is always possible
      to construct a SharedArrayBuffer using
      
        new WebAssembly.Memory({
          shared:true, initial:0, maximum:0 }).buffer.constructor;
      
      There are few things which I do not like of this approach, but I did
      not have better ideas:
      
      1. The complex logic of dobule flag + callback. However, this seemed
      the best way to me to not break embedders which rely on that flag
      being enabled by default.
      
      2. The fact that what actually matters is just whether the callback
      returns `true` once. It would be good to check that the callback gives
      a consistent return value, or to provide a better API that cannot be
      missunderstood.
      
      Bug: chromium:923807,chromium:1071424,chromium:1138860
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2867473Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74378}
      
      ---
      
      Bug: chromium:923807,chromium:1071424,chromium:1138860,chromium:1206187
      Change-Id: Ibc6b4f8c0e0827178b7f0cbe4b942444bbbe6216
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880215Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLutz Vahl <vahl@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Auto-Submit: Arthur Sonzogni <arthursonzogni@chromium.org>
      Commit-Queue: Hannes Payer <hpayer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74441}
      22f124ce
  13. 06 May, 2021 1 commit
    • Nico Hartmann's avatar
      Revert "[api] Add API callback setter for the SAB origin trial" · 4ce88f56
      Nico Hartmann authored
      This reverts commit bc1eb7b4.
      
      Reason for revert: https://ci.chromium.org/ui/p/chromium/builders/try/android-pie-arm64-rel/369203/overview
      
      Original change's description:
      > [api] Add API callback setter for the SAB origin trial
      >
      > This change makes it possible to enable SharedArrayBuffer per Context,
      > controlling whether it should be enabled or not with a callback. The
      > previous implementation of the reverse origin trial for
      > SharedArrayBuffer was broken, since the feature could only be enabled
      > globally per process, and only if the feature flag is set early enough
      > in the v8 initialization. This does not play well with how origin
      > trials work.
      >
      > The implementation is similar to the callbacks that already exist for
      > the origin trials for WebAssembly simd and exceptions.
      >
      > SharedArrayBuffer is still controlled by the flag
      > harmony_sharedarraybuffer. If that flag is disabled, then
      > SharedArrayBuffer is disabled unconditionally. On top of that, this CL
      > introduces a new flag for enabling SharedArrayBuffer per context. If
      > that flag is set, a callback is used to determine whether
      > SharedArrayBuffer should be enabled.
      >
      >
      > Note that this only controls whether the SharedArrayBuffer constructor
      > should be exposed on the global object or not. It is always possible
      > to construct a SharedArrayBuffer using
      >
      >   new WebAssembly.Memory({
      >     shared:true, initial:0, maximum:0 }).buffer.constructor;
      >
      >
      > There are few things which I do not like of this approach, but I did
      > not have better ideas:
      >
      > 1. The complex logic of dobule flag + callback. However, this seemed
      > the best way to me to not break embedders which rely on that flag
      > being enabled by default.
      >
      > 2. The fact that what actually matters is just whether the callback
      > returns `true` once. It would be good to check that the callback gives
      > a consistent return value, or to provide a better API that cannot be
      > missunderstood.
      >
      >
      > Bug: chromium:923807,chromium:1071424,chromium:1138860
      > Change-Id: Ibe3776fad4d3bff5dda9066967e4b20328014266
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2867473
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#74378}
      
      Bug: chromium:923807
      Bug: chromium:1071424
      Bug: chromium:1138860
      Change-Id: Iec678dee130db891c2096e47bc072a5d77ae9476
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874403
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarLutz Vahl <vahl@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74404}
      4ce88f56
  14. 05 May, 2021 1 commit
    • Antonio Sartori's avatar
      [api] Add API callback setter for the SAB origin trial · bc1eb7b4
      Antonio Sartori authored
      This change makes it possible to enable SharedArrayBuffer per Context,
      controlling whether it should be enabled or not with a callback. The
      previous implementation of the reverse origin trial for
      SharedArrayBuffer was broken, since the feature could only be enabled
      globally per process, and only if the feature flag is set early enough
      in the v8 initialization. This does not play well with how origin
      trials work.
      
      The implementation is similar to the callbacks that already exist for
      the origin trials for WebAssembly simd and exceptions.
      
      SharedArrayBuffer is still controlled by the flag
      harmony_sharedarraybuffer. If that flag is disabled, then
      SharedArrayBuffer is disabled unconditionally. On top of that, this CL
      introduces a new flag for enabling SharedArrayBuffer per context. If
      that flag is set, a callback is used to determine whether
      SharedArrayBuffer should be enabled.
      
      
      Note that this only controls whether the SharedArrayBuffer constructor
      should be exposed on the global object or not. It is always possible
      to construct a SharedArrayBuffer using
      
        new WebAssembly.Memory({
          shared:true, initial:0, maximum:0 }).buffer.constructor;
      
      
      There are few things which I do not like of this approach, but I did
      not have better ideas:
      
      1. The complex logic of dobule flag + callback. However, this seemed
      the best way to me to not break embedders which rely on that flag
      being enabled by default.
      
      2. The fact that what actually matters is just whether the callback
      returns `true` once. It would be good to check that the callback gives
      a consistent return value, or to provide a better API that cannot be
      missunderstood.
      
      
      Bug: chromium:923807,chromium:1071424,chromium:1138860
      Change-Id: Ibe3776fad4d3bff5dda9066967e4b20328014266
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2867473Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74378}
      bc1eb7b4
  15. 30 Apr, 2021 1 commit
  16. 28 Apr, 2021 2 commits
  17. 27 Apr, 2021 1 commit
  18. 23 Apr, 2021 1 commit
  19. 21 Apr, 2021 1 commit
  20. 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
  21. 16 Apr, 2021 3 commits
  22. 15 Apr, 2021 1 commit
  23. 14 Apr, 2021 2 commits
  24. 13 Apr, 2021 1 commit
  25. 12 Apr, 2021 1 commit
  26. 08 Apr, 2021 2 commits
  27. 31 Mar, 2021 3 commits
  28. 23 Mar, 2021 1 commit
    • Andreas Haas's avatar
      [api] Add callback to set up conditional features · 16d9298a
      Andreas Haas authored
      Origin trials allow webpages to use experimental features even though
      the features are not yet enabled by default. These features will then
      get enabled per execution context: it is possible that the feature is
      enabled in one execution context but disabled in another execution
      context. In V8 we check for origin trials by calling a callback provided
      by the embedder that takes the context as a parameter and returns
      whether a feature is enabled in this context or not.
      
      This approach fails when a feature changes the context itself, e.g. by
      extending the global object. In that case the context is not available
      yet to check for the origin trial.
      
      To solve the problem this CL adds a new API function that can be called
      by the embedder to notify V8 that context with the origin trial
      information is finished. After that V8 can read the origin trial
      information from the context and extend e.g. the global object with the
      origin trial features.
      
      Additionally to the API this CL also adds code to enable the
      WebAssembly.Exception constructor conditionally, depending on whether
      it has been enabled by an origin trial or not.
      
      The Blink-side change: https://crrev.com/c/2775573
      
      R=ulan@chromium.org, jkummerow@chromium.org
      
      Change-Id: Ic05c4a89eb3e0e31469e49da8767d630c43b2e00
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773287Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73597}
      16d9298a
  29. 15 Mar, 2021 1 commit
  30. 12 Mar, 2021 1 commit