1. 13 Jan, 2022 1 commit
  2. 24 Aug, 2021 1 commit
    • Dan Elphick's avatar
      Reland "[include] Split out v8.h" · ec06bb6c
      Dan Elphick authored
      This is a reland of d1b27019
      
      Fixes include:
      Adding missing file to bazel build
      Forward-declaring classing before friend-classing them to fix win/gcc
      Add missing v8-isolate.h include for vtune builds
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
      Bug: v8:11965
      Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76460}
      ec06bb6c
  3. 23 Aug, 2021 2 commits
    • Dan Elphick's avatar
      Revert "[include] Split out v8.h" · 44fe02ce
      Dan Elphick authored
      This reverts commit d1b27019.
      
      Reason for revert: Broke vtune build, tsan build and possibly others
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Bug: v8:11965
      Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76428}
      44fe02ce
    • Dan Elphick's avatar
      [include] Split out v8.h · d1b27019
      Dan Elphick authored
      This moves every single class/function out of include/v8.h into a
      separate header in include/, which v8.h then includes so that
      externally nothing appears to have changed.
      
      Every include of v8.h from inside v8 has been changed to a more
      fine-grained include.
      
      Previously inline functions defined at the bottom of v8.h would call
      private non-inline functions in the V8 class. Since that class is now
      in v8-initialization.h and is rarely included (as that would create
      dependency cycles), this is not possible and so those methods have been
      moved out of the V8 class into the namespace v8::api_internal.
      
      None of the previous files in include/ now #include v8.h, which means
      if embedders were relying on this transitive dependency then it will
      give compile failures.
      
      v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      that Chrome continue to compile but that change will be reverted once
      those transitive #includes in chrome are changed to include it directly.
      
      Full design:
      https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      
      Bug: v8:11965
      Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76424}
      d1b27019
  4. 18 Aug, 2021 1 commit
  5. 16 Aug, 2021 2 commits
  6. 12 Aug, 2021 2 commits
  7. 11 Aug, 2021 1 commit
  8. 10 Aug, 2021 2 commits
  9. 09 Aug, 2021 3 commits
    • Camillo Bruni's avatar
      Reland "[counters] Fix reentrant timers for V8.Execute" · f688fe08
      Camillo Bruni authored
      This is a reland of fffcbaea
      
      Additional fixes:
      - Relax IsStarted DCHECKs in ElapsedTimer for paused_elapsed
      - Add LogEventStatus enum in the API for better testing
      - Rename Logger::StartEnd enum values to kXXX
      - Add additional NestedTimedHistogramScope tests
      
      Original change's description:
      > [counters] Fix reentrant timers for V8.Execute
      >
      > This CL fixes a long standing issue where reentering TimedHistograms
      > scopes would cause spurious measurements. Only the non-nested scopes
      > yielded correct results.
      >
      > Due to the changed numbers, the V8.Execute histogram is renamed to
      > V8.ExecuteMicroSeconds. Note that this histogram is also guarded
      > behind the --slow-histograms flag due to the additional overhead.
      >
      > Unlike before, it does no longer include time for external callbacks
      > and only measures self time. The following example illustrates the
      > new behaviour:
      >
      > 1. Enter V8:           |--+.......+--| self-time: 4 units (reported)
      > 2. Exit V8 (callback):    |-+...+-|    self-time: 2 units (ignored)
      > 3. Re-enter V8:             |---|      self-time: 3 units (reported)
      >
      > This would result in 2 histogram entries with 4 time units for the first
      > V8 slice and 3 units for the nested part. Note that the callback time
      > itself is ignored.
      >
      > This CL attempts to clean up how TimedHistograms work:
      > - Histogram: the base class
      > - TimedHistograms: used for time-related histograms that are not nested
      > - NestedTimeHistograms: Extends TimedHistograms and is used for nested
      >   histograms
      >
      > This CL changes Histograms to not measure time themselves. Measurements
      > happen in the *HistogramScopes:
      > - BaseTimedHistogramScope: Base functionality
      > - TimedHistogramScope: For non-nested measurements
      > - NestedTimedHistogramScope: For nested measurements
      > - PauseNestedTimedHistogramScope: Ignore time during a given scope.
      >   This is used to pause timers during callbacks.
      >
      > Additional changes:
      > - ExternalCallbackScope now contains a PauseNestedTimedHistogramScope
      >   and always sets VMState<EXTERNAL>
      >
      > Bug: v8:11946
      > Change-Id: I45e4b7ff77b5948b605dd50539044cb26222fa21
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001345
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Reviewed-by: Victor Gomes <victorgomes@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#76111}
      
      Bug: v8:11946
      Change-Id: Ic2eef7456fbc245febcf780b23418f6ab0bebdb7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3080566
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76180}
      f688fe08
    • Sathya Gunasekaran's avatar
      [api] Implement signature checks using instance types · 7df6678c
      Sathya Gunasekaran authored
      Rather than depending on slow signature checks, receiver type checks are
      performed using fast numeric instance type checks.
      
      This CL adds a instance type range for embedders to assign values and
      uses these to perform type checks.
      
      Bug: v8:11476
      Change-Id: Ie8236ae47ca0ba93ae76a7e690b81aa0a2b0f3e2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2883623Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76162}
      7df6678c
    • Leszek Swirski's avatar
      [api] Add API for off-thread code cache deserialization · f888f48e
      Leszek Swirski authored
      To consume a code cache off-thread
      
        1. The embedder creates a CachedData object wrapping the data blob.
        2. The embedder calls ScriptCompiler::StartConsumingCodeCache with the
           CachedData, and receives a ScriptCompiler::CodeCacheConsumeTask
           which takes ownership of the CachedData.
        3. The embedder calls ScriptCompiler::CodeCacheConsumeTask::Run
           on a different thread.
        4. Once this completes, the embedded passes the completed task as an
           optional argument into Source constructor, and calls Compile as
           before.
      
      This is roughly similar to how streaming compilation works, with the
      QoL improvement that Source owns the CodeCacheConsumeTask and therefore
      we can reuse the same Compile method and do the off-thread finalization
      behind the scenes inside Compile.
      
      On the v8::internal side, ScriptCompiler::CodeCacheConsumeTask wraps a
      v8::internal::BackgroundDeserializeTask, which has a Run and a Finish
      method. The Run creates a LocalIsolate (again, similar to
      BackgroundCompileTask), calls some helpers on CodeSerializer, and stores
      the pre-finalization result in a OffThreadDeserializeData structure.
      This stores Persistent Handles to the off-thread initialized SFI and
      a vector of Scripts needing fixing up, and it owns the PersistentHandles
      object which owns those Handles. Finally, the Finish method consumes
      this OffThreadDeserializeData structure, fixes up Scripts, moves the
      SFI Handle into the caller HandleScope, and that's it.
      
      Since we don't yet have the source at off-thread deserialization time,
      the various code cache sanity checks are done without the source hash
      when deserializing, and the Finish method re-does them now that the
      source is available.
      
      Bug: chromium:1075999
      Change-Id: If1faf35ba3ef840fa4e735581d0b29c96c1d5fc8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067322
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76155}
      f888f48e
  10. 07 Jul, 2021 1 commit
  11. 23 Jun, 2021 2 commits
  12. 14 Jun, 2021 1 commit
  13. 09 Jun, 2021 1 commit
  14. 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
  15. 01 Jun, 2021 1 commit
  16. 21 May, 2021 1 commit
  17. 18 May, 2021 1 commit
  18. 17 May, 2021 1 commit
  19. 12 May, 2021 1 commit
  20. 10 May, 2021 1 commit
  21. 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
  22. 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
  23. 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
  24. 30 Apr, 2021 1 commit
  25. 28 Apr, 2021 2 commits
  26. 27 Apr, 2021 1 commit
  27. 23 Apr, 2021 1 commit
  28. 21 Apr, 2021 1 commit
  29. 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
  30. 16 Apr, 2021 1 commit
    • Shu-yu Guo's avatar
      Revert "[fastcall] Add support for leaf interface type checks" · 19467237
      Shu-yu Guo authored
      This reverts commit 6124a534.
      
      Reason for revert: On suspicion of blocking V8 roll: https://ci.chromium.org/ui/p/chromium/builders/try/win10_chromium_x64_rel_ng/839568/overview
      
      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
      Change-Id: Ic99ec616310f0f75800c3dad393b5d2d685b76ab
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2829988
      Auto-Submit: Shu-yu Guo <syg@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@{#74016}
      19467237