1. 02 Mar, 2022 1 commit
  2. 15 Feb, 2022 1 commit
  3. 09 Sep, 2021 1 commit
  4. 14 Jun, 2021 1 commit
  5. 22 Feb, 2021 1 commit
    • Mythri A's avatar
      [turboprop] Reduce BytecodeBudgetInterrupt overhead from Turboprop · 5b783479
      Mythri A authored
      Earlier we used the same interrupt budget always and waited for higher
      number of ticks when tiering up from Turboprop to TurboFan. On some of
      the real world pages this adds a reasonable overhead for processing
      these interrupts. This cl sets the interrupt budget to a higher value so
      there are fewer interrupts. This cl:
      1. Sets the interrupt budget on feedback cell to
      FLAG_interrupt_budget * scale factor when we install optimized code.
      2. Resets the budget to FLAG_interrupt_budget when there is a
      deoptimization.
      3. Updates the runtime profiler to remove the scaling of number of ticks
      needed for optimization when tiering up from TP to TF.
      
      On sheets benchmark, we spend 40-50ms when servicing interrupts from
      Turboprop code. This change brings it down to ~7ms. We also see
      improvements on other pages.
      
      
      Bug: v8:9684
      Change-Id: Ia3e5e998d1fff44f2e08a240a8769b7ebe794da2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696661
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72906}
      5b783479
  6. 22 Jan, 2021 1 commit
  7. 10 Nov, 2020 1 commit
    • Jakob Gruber's avatar
      [factory] Refactor JSFunction construction · 09ef5458
      Jakob Gruber authored
      Construction of JSFunction objects is complex, mostly due to the
      existence of multiple functions kinds (JS, wasm, builtin, test, ...)
      that are all created slightly differently. For example, JS functions
      may come with an existing FeedbackCell (and FeedbackVector), while
      builtins and wasm functions always use the many_closures_cell (without
      a vector).
      
      Prior to this CL, construction logic was scattered over a family of
      7 functions, without a clearly defined chokepoint for header
      initialization. This was hard to understand, hard to modify, and
      needlessly inefficient (by setting some fields twice).
      
      This CL fixes all that by introducing JSFunctionBuilder. The BuildRaw
      method is the chokepoint for allocation and initialization, and Build
      performs common pre- and post-work.
      
      Future work:
      - Remove now-deprecated functions.
      - Untangle SFI/Map/JSFunction construction and remove
        Factory::NewFunction and NewFunctionArgs.
      
      Bug: v8:8888
      Change-Id: I709a2a44ee02e10593a4c9afe43d4d2c6d6351c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2527098Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71084}
      09ef5458
  8. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored
      This CL splits the class definitions per .tq file, to realize the
      following relationship:
      A class defined in src/objects/foo.tq has a C++ definition in
      src/objects/foo.h. Torque then generates:
      
      - torque-generated/src/objects/foo-tq.inc
        An include file (no proper header) to be included in src/objects/foo.h
        containing the Torque-generated C++ class definition.
      
      - torque-generated/src/objects/foo-tq-inl.inc
        An include file (no proper header) to be included in
        src/objects/foo-inl.h containing inline function definitions.
      
      - torque-generated/src/objects/foo-tq.cc
        A source file including src/objects/foo-inl.h that contains non-inline
        function definitions.
      
      Advantages of this approach:
      - Avoid big monolithic headers and preserve the work that went into
        splitting objects.h
      - Moving a definition to Torque keeps everything in the same place
        from a C++ viewpoint, including a fully Torque-generated C++ class
        definition.
      - The Torque-generated include files do not need to be independent
        headers, necessary includes or forward declarations can just be added
        to the headers that include them.
      
      Drive-by changes:
      A bunch of definitions and files had to be moved or created to realize
      a consistent 1:1 relationship between .tq files and C++ headers.
      
      
      Bug: v8:7793
      TBR: hpayer@chromium.org
      Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
  9. 25 Feb, 2020 1 commit
    • Mythri A's avatar
      Set bytecode budget to interrupt_budget when allocating feedback vector · 443721bd
      Mythri A authored
      We use the same interrupt to both allocate feedback vectors and
      for updating the profiler ticks. If there is a feedback vector already
      available, we just increment the profiler ticks that we use to mark
      for optimizing function. Calling JSFunction::EnsureFeedbackVector
      allocates a feedback vector, but doesn't reset the budget, so we
      optimize much earlier than expected. This is currently only a problem
      with %PrepareFunctionForOptimize that doesn't reset the budget. Other
      code paths do also reset the interrupt budget.
      
      Bug: chromium:10243
      Change-Id: I611a9202e5e71077bf897def5959bcfe11b8fdf4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064980
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66426}
      443721bd
  10. 20 Jan, 2020 1 commit
    • Mythri A's avatar
      Only flush feedback vector on bytecode flush · 92df7d10
      Mythri A authored
      When bytecode is flushed we also want to flush the feedback vectors to
      save memory. There was a bug in this code and we flushed
      ClosureFeedbackCellArray too. Flushing ClosureFeedbackCellArrays causes
      the closures created by this function before and after the bytecode
      flush to have different feedback cells and hence different feedback
      vectors. This cl fixes it so we only flush feedback vectors on a
      bytecode flush.
      
      Also this cl pretenures ClosureFeedbackCellArrays. Only FeedbackCells
      and FeedbackVectors can contain ClosureFeedbackCellArrays which are
      pretenured, so it is better to pretenure ClosureFeedbackCellArrays as
      well.
      
      
      Bug: chromium:1031479
      Change-Id: I7831441a95420b9e5711f4143461f1eb7fa1616a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1980582
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65866}
      92df7d10
  11. 07 Oct, 2019 1 commit
  12. 23 May, 2019 1 commit
  13. 08 May, 2019 1 commit
  14. 25 Apr, 2019 1 commit
  15. 10 Apr, 2019 3 commits
  16. 15 Feb, 2019 1 commit
  17. 09 Jan, 2019 1 commit
  18. 20 Dec, 2018 1 commit
  19. 18 Dec, 2018 1 commit
  20. 17 Dec, 2018 1 commit
  21. 14 Dec, 2018 1 commit
  22. 05 Nov, 2018 1 commit
  23. 14 Sep, 2018 3 commits
  24. 04 Sep, 2018 1 commit
  25. 29 Aug, 2018 1 commit
  26. 27 Aug, 2018 1 commit
    • Sathya Gunasekaran's avatar
      [Intl] Correctly pass usage option to Collator · 59c03fef
      Sathya Gunasekaran authored
      The spec specifies that search and standard can not be valid values
      for the collation extension keyword. Instead users are expected to use
      the options bag to set the correct usage options.
      
      But, ICU expects the usage option to be set through the collation
      extension value.
      
      In this patch, we set the usage option using the collation extension
      value in ICU. For resolvedOptions, we filter out this extension value
      using ICU to be spec compatible.
      
      Previously, we stored the usage option on the JSCollator instance. But
      this patch changes the logic to just look it up from the icu::Collator
      when required. This saves one word of memory.
      
      This fails a test262 that was incorrectly fixed. A follow on patch
      will fix the test262 test.
      
      Bug: v8:5751
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I8c66c6286287e686f4cd152fa1301f9d51c38654
      Reviewed-on: https://chromium-review.googlesource.com/1180488Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55437}
      59c03fef
  27. 14 Aug, 2018 1 commit
  28. 08 Aug, 2018 1 commit
    • Sathya Gunasekaran's avatar
      [Intl] Optimize Intl.Collator · 363fe1eb
      Sathya Gunasekaran authored
      This patch ports most of the Intl.Collator from JS to C++.
      
      The Intl.Collator object no longer stores all the resolved
      values. Instead these are looked up on demand as part of
      Intl.Collator.prototype.resolvedOptions(), saving several words. In
      the future, we can cache the result of the resolvedOptions as well.
      
      In this patch, we use ICU to do parsing of the unicode extension in
      the bcp47 language tag instead of using a custom extension parser.
      
      This patch also fixes several spec compliance bugs as well.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Iaaa7be4a628404da1bd83d882e04a2c6de70ebd9
      Bug: v8:5751, v8:7480
      Reviewed-on: https://chromium-review.googlesource.com/1165084
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54965}
      363fe1eb