1. 09 Mar, 2022 1 commit
    • Camillo Bruni's avatar
      [runtime] Clean up runtime function Arguments accesses · cead6573
      Camillo Bruni authored
      Replace all CONVERT_XXX_ARG_XXX() macros from runtime-util.h with direct
      calls to Arguments or the fully expanded equivalent.
      
      - This replaces many of the hard CHECKs with DCHECK (as is common
        practice in most V8 code)
      - Instead of relying on verbose comments we now have readable code
      - Rename Arguments.::xxx_at with Arguments::xxx_value_at since these
        methods don't return the Object but rather their double/int value
      
      - Add Oddball::ToBool helper
      - Add and use v8::internal::PropertyAttributesFromInt helper
      - Add stronger DCHECK for PropertyAttributes returned in
        GetPropertyAttributesWithInterceptorInternal
      
      
      
      Bug: v8:11263
      Change-Id: I8d531857e05d19f3198753b05af28d993a391854
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497768Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79418}
      cead6573
  2. 23 Jun, 2021 1 commit
  3. 09 Jan, 2020 1 commit
  4. 12 Oct, 2019 1 commit
  5. 23 May, 2019 1 commit
  6. 22 May, 2019 1 commit
  7. 20 May, 2019 2 commits
  8. 17 May, 2019 2 commits
  9. 15 Feb, 2019 1 commit
  10. 13 Nov, 2018 1 commit
  11. 03 Aug, 2018 1 commit
  12. 31 Jul, 2018 1 commit
  13. 31 May, 2018 1 commit
  14. 24 May, 2018 1 commit
  15. 09 Apr, 2018 1 commit
  16. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored
      This reverts commit f9a2e24b.
      
      Reason for revert: gc stress failures not all fixed by follow up.
      
      Original change's description:
      > [cleanup] Refactor the Factory
      > 
      > There is no good reason to have the meat of most objects' initialization
      > logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      > this CL changes the protocol between Heap and Factory to be AllocateRaw,
      > and all object initialization work after (possibly retried) successful
      > raw allocation happens in the Factory.
      > 
      > This saves about 20KB of binary size on x64.
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      > Reviewed-on: https://chromium-review.googlesource.com/959533
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52416}
      
      TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
      
      Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored
      There is no good reason to have the meat of most objects' initialization
      logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      this CL changes the protocol between Heap and Factory to be AllocateRaw,
      and all object initialization work after (possibly retried) successful
      raw allocation happens in the Factory.
      
      This saves about 20KB of binary size on x64.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      Reviewed-on: https://chromium-review.googlesource.com/959533
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  17. 28 Feb, 2018 1 commit
  18. 01 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Optimize fast enum cache driven for..in. · f1ec44e2
      Benedikt Meurer authored
      This CL adds support to optimize for..in in fast enum-cache mode to the
      same degree that it was optimized in Crankshaft, without adding the same
      deoptimization loop that Crankshaft had with missing enum cache indices.
      That means code like
      
        for (var k in o) {
          var v = o[k];
          // ...
        }
      
      and code like
      
        for (var k in o) {
          if (Object.prototype.hasOwnProperty.call(o, k)) {
            var v = o[k];
            // ...
          }
        }
      
      which follows the https://eslint.org/docs/rules/guard-for-in linter
      rule, can now utilize the enum cache indices if o has only fast
      properties on the receiver, which speeds up the access o[k]
      significantly and reduces the pollution of the global megamorphic
      stub cache.
      
      For example the micro-benchmark in the tracking bug v8:6702 now runs
      faster than ever before:
      
       forIn: 1516 ms.
       forInHasOwnProperty: 1674 ms.
       forInHasOwnPropertySafe: 1595 ms.
       forInSum: 2051 ms.
       forInSumSafe: 2215 ms.
      
      Compared to numbers from V8 5.8 which is the last version running with
      Crankshaft
      
       forIn: 1641 ms.
       forInHasOwnProperty: 1719 ms.
       forInHasOwnPropertySafe: 1802 ms.
       forInSum: 2226 ms.
       forInSumSafe: 2409 ms.
      
      and V8 6.0 which is the current stable version with TurboFan:
      
       forIn: 1713 ms.
       forInHasOwnProperty: 5417 ms.
       forInHasOwnPropertySafe: 5324 ms.
       forInSum: 7556 ms.
       forInSumSafe: 11067 ms.
      
      It also improves the throughput on the string-fasta benchmark by
      around 7-10%, and there seems to be a ~5% improvement on the
      Speedometer/React benchmark locally.
      
      For this to work, the ForInPrepare bytecode was split into
      ForInEnumerate and ForInPrepare, which is very similar to how it was
      handled in Fullcodegen initially. In TurboFan we introduce a new
      operator LoadFieldByIndex that does the dynamic property load.
      
      This also removes the CheckMapValue operator again in favor of
      just using LoadField, ReferenceEqual and CheckIf, which work
      automatically with the EscapeAnalysis and the
      BranchConditionElimination.
      
      Bug: v8:6702
      Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
      Reviewed-on: https://chromium-review.googlesource.com/645949
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47768}
      f1ec44e2
  19. 30 Aug, 2017 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Unify enum cache handling. · 562663d5
      Benedikt Meurer authored
      Introduce a proper empty_descriptor_array, which has the proper layout
      (length is 2 and the two fields are set properly). Also add a special
      EnumCache class and a matching empty_enum_cache. The contract now is
      that we only need to check the EnumLength on the map to know whether we
      are allowed to use the enum cache. This greatly simplifies the handling
      of the enum cache (and also the descriptor arrays), especially for the
      future work on optimizing keyed access via the enum cache indices.
      
      Bug: v8:6702
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I5ef517a3041163cd65ef003f691139ea52233e83
      Reviewed-on: https://chromium-review.googlesource.com/641030
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47697}
      562663d5
  20. 24 Mar, 2017 1 commit
  21. 08 Feb, 2017 1 commit
  22. 29 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Remove special JSForInStep and JSForInDone. · 1915762c
      bmeurer authored
      These JavaScript operators were special hacks to ensure that we always
      operate on Smis for the magic for-in index variable, but this never
      really worked in the OSR case, because the OsrValue for the index
      variable didn't have the proper information (that we have for the
      JSForInPrepare in the non-OSR case).
      
      Now that we have loop induction variable analysis and binary operation
      hints, we can just use JSLessThan and JSAdd instead with appropriate
      Smi hints, which handle the OSR case by inserting Smi checks (that are
      always true). Thanks to OSR deconstruction and loop peeling these Smi
      checks will be hoisted so they don't hurt the OSR case too much.
      
      Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since
      we have to lower it to JSLessThan to get the loop induction variable
      goodness.
      
      R=epertoso@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2289613002
      Cr-Commit-Position: refs/heads/master@{#38968}
      1915762c
  23. 01 Aug, 2016 1 commit
    • cbruni's avatar
      [keys] Trigger [[getOwnPropertyDescriptor]] trap on proxies for Object.keys · f4f06c50
      cbruni authored
      This CL fixes a long-standing bug with Object.keys where the enumerability
      check was omitted if the [ownKeys] trap is not present. The only distinction the
      KeyAccumulator needs is whether it collects keys for for-in (is_for_in_) or not.
      ForInFilter performs a separate step to filter out non-enumerable keys later-on
      while in all the other use-cases we have to filter keys.
      
      BUG=v8:1543, v8:5250
      
      Review-Url: https://codereview.chromium.org/2176113009
      Cr-Commit-Position: refs/heads/master@{#38199}
      f4f06c50
  24. 21 Jul, 2016 1 commit
  25. 07 Jul, 2016 1 commit
  26. 14 Jun, 2016 1 commit
  27. 13 Jun, 2016 2 commits
  28. 08 Jun, 2016 1 commit
    • jkummerow's avatar
      Keep prototype maps in dictionary mode until ICs see them · be0494ba
      jkummerow authored
      Adding properties to prototypes is faster when we don't force their
      maps into fast mode yet. Once a prototype shows up in the IC system,
      its setup phase is likely over, and it makes sense to transition it
      to fast properties.
      This patch speeds up the microbenchmark in the bug by 20x.
      Octane-Typescript sees a 3% improvement.
      
      BUG=chromium:607010
      
      Review-Url: https://codereview.chromium.org/2036493006
      Cr-Commit-Position: refs/heads/master@{#36828}
      be0494ba
  29. 30 May, 2016 1 commit
    • cbruni's avatar
      [api] Add more parameters to Object::GetPropertyNames · 63efe9e4
      cbruni authored
      Expose more or less the full functionality of the KeyAccumulator in the API:
      - use the PropertyFilter introduced for GetOwnPropertyNames
      - use KeyCollectionLimit for OWN_ONLY or INLCUDE_PROTOS
      - use IndexFilter to eithe SKIP_INDICES or INCLUDE_INDICES
      
      Rewire Object::GetOwnPropertyNames to use GetPropertyNames.
      
      BUG=chromium:148757
      
      Review-Url: https://codereview.chromium.org/2002203002
      Cr-Commit-Position: refs/heads/master@{#36595}
      63efe9e4
  30. 25 May, 2016 1 commit
  31. 24 May, 2016 3 commits
  32. 23 Mar, 2016 1 commit
    • cbruni's avatar
      [proxies] use [[GetPrototypeOf]] trap in for-in key accumulation · 2efc1381
      cbruni authored
      With the recent spec change removing the [[Enumerate]] internal method, we now
      have to walk the complete prototype chain. This implies that we call the
      [[GetPrototypeOf]] trap on proxies.
      
      As a secondary change we now trigger the [[GetOwnProperty]] trap for the for-in
      filter step to see whether the properties are still enumerable. Before we did this
      in the key-accumulation phase. This way we slightly reduce the number of traps
      invoked. Whilst this is not ideal, it comes closer to the Spec's example
      implementation.
      
      BUG=v8:1543, v8:4768
      LOG=n
      
      Review URL: https://codereview.chromium.org/1748923003
      
      Cr-Commit-Position: refs/heads/master@{#35017}
      2efc1381
  33. 07 Mar, 2016 2 commits