1. 15 Nov, 2021 1 commit
  2. 09 Nov, 2021 1 commit
  3. 29 Oct, 2021 1 commit
    • Samuel Groß's avatar
      Introduce CagedPointer · afd15549
      Samuel Groß authored
      A CagedPointer is guaranteed to point into the Virtual Memory Cage and
      will for example be used for ArrayBuffer backing stores when the heap
      sandbox is enabled. In the current implementation, CagedPointers are
      stored as offsets from the cage base, shifted to the left. Because the
      cage base address is usually available in a register, accessing a
      CagedPointer is very efficient, requiring only an additional shift and
      add operation.
      
      Bug: chromium:1218005
      Change-Id: Ifc8c088e3862400672051a8c52840514dee2911f
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3123417Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77614}
      afd15549
  4. 13 Oct, 2021 1 commit
    • Joyee Cheung's avatar
      [class] Add IC support for defining class fields to replace runtime call · 713ebae3
      Joyee Cheung authored
      Introduces several new runtime mechanics for defining private fields,
      including:
        - Bytecode StaKeyedPropertyAsDefine
        - Builtins StoreOwnIC{Trampoline|Baseline|_NoFeedback}
        - Builtins KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic}
        - TurboFan IR opcode JSDefineProperty
      
      These new operations can reduce a runtime call per class field into a
      more traditional Store equivalent. In the microbenchmarks, this
      results in a substantial win over the status quo (~8x benchmark score
      for single fields with the changes, ~20x with multiple fields).
      
      The TurboFan JSDefineProperty op is lowered in
      JSNativeContextSpecialization, however this required some hacks.
      Because private fields are defined as DONT_ENUM when added to the
      object, we can't find a suitable transition using the typical data
      property (NONE) flags. I've added a mechanism to specify the required
      PropertyAttributes for the transition we want to look up.
      
      Details:
      
      New bytecodes:
        - StaKeyedPropertyAsDefine, which is essentially StaKeyedProperty
          but with a different IC builtin (KeyedDefineOwnIC). This is a
          bytecode rather than a flag for the existing StaKeyedProperty in
          order to avoid impacting typical keyed stores in any way due to
          additional branching and testing.
      
      New builtins:
        - StoreOwnIC{TTrampoline|Baseline|_NoFeedback} is now used for
          StaNamedOwnProperty. Unlike the regular StoreIC, this variant will
          no longer look up the property name in the prototype.
          In adddition, this CL changes an assumption that
          StoreNamedOwnProperty can't result in a map transition, as we
          can't rely on the property already being present in the Map due
          to an object literal boilerplate.
      
          In the context of class features, this replaces the runtime
          function %CreateDataProperty().
      
        - KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} is used by the
          new StaKeyedPropertyAsDefine bytecode. This is similar to an
          ordinary KeyedStoreIC, but will not check the prototype for
          setters, and for private fields, will take the slow path if the
          field already exists.
      
          In the context of class features, this replaces the runtime
          function %AddPrivateField().
      
      TurboFan IR:
        - JSDefineProperty is introduced to represent a situation where we
          need to use "Define" semantics, in particular, it codifies that we
          do not consult the prototype chain, and the semantics relating to
          private fields are implied as well.
      
      R=leszeks@chromium.org, syg@chromium.org, rmcilroy@chromium.org
      
      Bug: v8:9888
      Change-Id: Idcc947585c0e612f9e8533aa4e2e0f8f0df8875d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2795831Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#77377}
      713ebae3
  5. 20 Sep, 2021 1 commit
  6. 10 Sep, 2021 1 commit
  7. 09 Sep, 2021 1 commit
  8. 02 Sep, 2021 1 commit
  9. 30 Aug, 2021 4 commits
  10. 12 Aug, 2021 1 commit
  11. 05 Aug, 2021 1 commit
  12. 04 Aug, 2021 1 commit
  13. 03 Aug, 2021 1 commit
  14. 29 Jul, 2021 1 commit
  15. 26 Jul, 2021 1 commit
  16. 22 Jul, 2021 1 commit
  17. 20 Jul, 2021 3 commits
  18. 19 Jul, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Make JSFunction bg-serialized · 0dba97f8
      Jakob Gruber authored
      This wraps up the transition away from kSerialized ref kinds.
      
      Since JSFunctionRef is a complex type, we don't attempt full
      consistency on the background thread. Instead, we serialize functions
      on the background in a partially-racy manner, in which consistency
      between different JSFunction fields is *not* guaranteed. Consistency
      is later verified through a new compilation dependency kind during
      finalization.
      
      Bug: v8:7790, v8:12004
      Change-Id: Ic2b78af9c9fe183c8769d323132bb304b151dc75
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968404
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75789}
      0dba97f8
  19. 08 Jul, 2021 1 commit
  20. 01 Jul, 2021 1 commit
  21. 30 Jun, 2021 2 commits
  22. 18 Jun, 2021 1 commit
  23. 16 Jun, 2021 1 commit
  24. 10 Jun, 2021 1 commit
  25. 07 Jun, 2021 2 commits
  26. 25 May, 2021 1 commit
  27. 18 May, 2021 1 commit
  28. 17 May, 2021 1 commit
  29. 06 May, 2021 2 commits
    • Fanchen Kong's avatar
      Collect receiver to feedback for prototype.apply · 519c82ce
      Fanchen Kong authored
      When a function is invoked by prototype.apply, it may undergo following transformation in the JSCallReducer:
      	receiver.apply(this, args) ->
      	this.receiver(...args) Since the new target (also the receiver of apply()) is not collected to the feedback slot, further speculative optimization on the new target is not available if the new target
      is not a heapconstant.
      
      With this CL, the receiver will be collected to the feedback instead of the target if the target is a prototype.apply. It may improve the performance of the following usecase by ~80%.
      
      function reduceArray(func, arr, r) {
          for (var i = 0, len = arr.length; i < len; i++) {
                  r = func.apply(null, r, arr[i]);
          }
          return r;
      }
      
      var a = 0; for (var i = 0; i < 10000000; i++) {
          a += reduceArray(Math.imul, [5,6,2,3,7,6,8,3,7,9,2,5,], 1);
      }
      console.log(a);
      
      This CL also improves the runTime score of JetStream2/richards-wasm by ~45% in default, ~60% with --turbo-inline-js-wasm-calls.
      
      Change-Id: I542eb8d3fcb592f4e0993af93ba1af70e89c3982
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639813
      Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74413}
      519c82ce
    • Georg Neis's avatar
      [compiler] Get rid of ShouldHaveBeenSerialized() · 13a89b00
      Georg Neis authored
      This is a simplification and cleanup.
      
      Bug: v8:7790
      Change-Id: I93a3ed2c9ddce4e300f25032be2085aef915ed8d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874655
      Auto-Submit: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74396}
      13a89b00
  30. 05 May, 2021 3 commits