1. 03 Aug, 2018 1 commit
  2. 31 Jul, 2018 1 commit
  3. 31 May, 2018 1 commit
  4. 24 May, 2018 1 commit
  5. 09 Apr, 2018 1 commit
  6. 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
  7. 28 Feb, 2018 1 commit
  8. 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
  9. 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
  10. 24 Mar, 2017 1 commit
  11. 08 Feb, 2017 1 commit
  12. 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
  13. 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
  14. 21 Jul, 2016 1 commit
  15. 07 Jul, 2016 1 commit
  16. 14 Jun, 2016 1 commit
  17. 13 Jun, 2016 2 commits
  18. 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
  19. 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
  20. 25 May, 2016 1 commit
  21. 24 May, 2016 3 commits
  22. 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
  23. 07 Mar, 2016 5 commits
  24. 04 Feb, 2016 1 commit
  25. 25 Jan, 2016 1 commit
    • bmeurer's avatar
      [for-in] Further refactorings and unification around for-in. · 88f9995d
      bmeurer authored
      Cleanup %ForInPrepare runtime entry, and unify common logic with
      %ForInEnumerate (renamed from %GetPropertyNamesFast). Also introduce
      a TupleType to properly type JSForInPrepare and its projections w/o
      special hacks in the Typer. And fix %ForInNext and JSForInNext to be
      consistent with fullcodegen again (after the proxy refactorings last
      quarter).
      
      R=jarin@chromium.org
      BUG=v8:3650
      LOG=n
      
      Review URL: https://codereview.chromium.org/1631583002
      
      Cr-Commit-Position: refs/heads/master@{#33487}
      88f9995d
  26. 22 Jan, 2016 1 commit
  27. 15 Jan, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Add ForInPrepare runtime function which returns a ObjectTriple. · 84f8a506
      rmcilroy authored
      Adds a ForInPrepare Runtime function which returns a triple of
      cache_type, cache_array and cache_length.
      
      This requires adding support to CEntryStub to call runtime functions
      which return a ObjectTriple - a struct containing three Object*
      pointers. Also did some cleanup of the x64 CEntryStub to avoid
      replicated code.
      
      Replaces the interpreter's use of the ad-hock InterpreterForInPrepare
      Runtime function with ForInPrepare in preparation for fixing deopt in
      BytecodeGraphBuilder for ForIn (which will be done in a followup CL).
      
      MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1576093004
      
      Cr-Commit-Position: refs/heads/master@{#33334}
      84f8a506
  28. 27 Aug, 2015 1 commit
  29. 18 Aug, 2015 1 commit
  30. 08 Jun, 2015 1 commit
  31. 01 Jun, 2015 1 commit
    • bmeurer's avatar
      [turbofan] First step towards sanitizing for-in and making it optimizable. · e2e47f30
      bmeurer authored
      In a nutshell: The FILTER_KEY builtin is gone, and was replaced by a
      simple runtime call to ForInFilter, which does everything and is even
      cheaper (because FILTER_KEY used to call into the runtime anyway).
      And ForInFilter returns either the name or undefined, which makes it
      possible to remove the control flow construction from the AstGraphBuilder,
      and thereby make both the initialization and the per-loop code of for-in
      optimizable later (in typed lowering).
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1160983004
      
      Cr-Commit-Position: refs/heads/master@{#28711}
      e2e47f30