1. 26 Feb, 2019 1 commit
  2. 22 Jan, 2019 1 commit
  3. 13 Nov, 2018 1 commit
  4. 09 Nov, 2018 1 commit
  5. 12 Oct, 2018 1 commit
  6. 25 Sep, 2018 1 commit
  7. 17 Sep, 2018 1 commit
  8. 14 Sep, 2018 1 commit
  9. 07 Sep, 2018 1 commit
  10. 23 Jun, 2018 1 commit
  11. 04 Apr, 2018 1 commit
  12. 26 Mar, 2018 1 commit
  13. 22 Mar, 2018 3 commits
  14. 20 Mar, 2018 2 commits
  15. 01 Mar, 2018 1 commit
    • Gabriel Charette's avatar
      [v8 platform] Get rid of unused ExpectedRuntime parameter. · 86b4b534
      Gabriel Charette authored
      With a temporary intermediate step to allow adapting embedders before
      getting rid of the ExpectedRuntime method altogether.
      
      The method is being renamed to CallOnWorkerThread() as an effort to
      go away from "background" nomenclature for worker threads ("background"
      usually refers to a priority but worker threads are commonly used for
      high priority tasks in v8).
      Other CLs will follow to rename other "background" APIs.
      
      Bug: v8:7310
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I2fd4eac7458708d4eacb0f4871c982a567a3865e
      Reviewed-on: https://chromium-review.googlesource.com/941442
      Commit-Queue: Gabriel Charette <gab@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51645}
      86b4b534
  16. 22 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Introduce a dedicated FeedbackCell. · aff1f378
      Benedikt Meurer authored
      This is preparatory cleanup work for eventually tracking the functions
      (rather than concrete closures) in the CALL_IC, also for builtins like
      the default PromiseCapability [[Resolve]] and [[Reject]] functions. It
      adds a new FeedbackCell type, which is used by JSFunctions consistently
      now to reference the feedback vector (or undefined if not the function
      is not compiled yet or is a native/asm.js function).
      
      This also changes the calling convention for FastNewClosure builtin and
      the JSCreateClosure operator in TurboFan to carry the FeedbackCell here
      instead of the parent FeedbackVector and the slot index. In addition we
      eliminate the now unused %InterpreterNewClosure runtime function.
      
      Bug: v8:2206, v8:7253, v8:7310
      Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656
      Reviewed-on: https://chromium-review.googlesource.com/928403
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51474}
      aff1f378
  17. 16 Nov, 2017 1 commit
  18. 15 Nov, 2017 1 commit
  19. 13 Oct, 2017 1 commit
  20. 28 Sep, 2017 1 commit
  21. 11 Aug, 2017 1 commit
  22. 03 Aug, 2017 1 commit
  23. 19 Jun, 2017 1 commit
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector (reland) · 24b7026d
      Leszek Swirski authored
      For interpreted functions, use the optimized code slot in the feedback
      vector to store an optimization marker (optimize/in optimization queue)
      rather than changing the JSFunction's code object. Then, adapt the
      self-healing mechanism to also dispatch based on this optimization
      marker. Similarly, replace SFI marking with optimization marker checks
      in CompileLazy.
      
      This allows JSFunctions to share optimization information (replacing
      shared function marking) without leaking this information across native
      contexts. Non I+TF functions (asm.js or --no-turbo) use a
      CheckOptimizationMarker shim which generalises the old
      CompileOptimized/InOptimizationQueue builtins and also checks the same
      optimization marker as CompileLazy and InterpreterEntryTrampoline.
      
      This is a reland of https://chromium-review.googlesource.com/c/509716
      
      Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe
      Reviewed-on: https://chromium-review.googlesource.com/535460Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45997}
      24b7026d
  24. 13 Jun, 2017 2 commits
    • Leszek Swirski's avatar
      Revert "[compiler] Drive optimizations with feedback vector" · 58978da6
      Leszek Swirski authored
      This reverts commit e39c9e02.
      
      Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561
      
      Original change's description:
      > [compiler] Drive optimizations with feedback vector
      > 
      > For interpreted functions, use the optimized code slot in the feedback vector
      > to store an optimization marker (optimize/in optimization queue) rather than
      > changing the JSFunction's code object. Then, adapt the self-healing mechanism
      > to also dispatch based on this optimization marker. Similarly, replace SFI
      > marking with optimization marker checks in CompileLazy.
      > 
      > This allows JSFunctions to share optimization information (replacing shared
      > function marking) without leaking this information across native contexts. Non
      > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
      > generalises the old CompileOptimized/InOptimizationQueue builtins and also
      > checks the same optimization marker as CompileLazy and
      > InterpreterEntryTrampoline.
      > 
      > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
      > Reviewed-on: https://chromium-review.googlesource.com/509716
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45901}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      
      Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94
      Reviewed-on: https://chromium-review.googlesource.com/532916Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45903}
      58978da6
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector · e39c9e02
      Leszek Swirski authored
      For interpreted functions, use the optimized code slot in the feedback vector
      to store an optimization marker (optimize/in optimization queue) rather than
      changing the JSFunction's code object. Then, adapt the self-healing mechanism
      to also dispatch based on this optimization marker. Similarly, replace SFI
      marking with optimization marker checks in CompileLazy.
      
      This allows JSFunctions to share optimization information (replacing shared
      function marking) without leaking this information across native contexts. Non
      I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
      generalises the old CompileOptimized/InOptimizationQueue builtins and also
      checks the same optimization marker as CompileLazy and
      InterpreterEntryTrampoline.
      
      Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
      Reviewed-on: https://chromium-review.googlesource.com/509716
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45901}
      e39c9e02
  25. 18 Apr, 2017 1 commit
  26. 23 Feb, 2017 2 commits
  27. 22 Feb, 2017 1 commit
  28. 30 Jan, 2017 2 commits
  29. 31 Aug, 2016 1 commit
  30. 22 Aug, 2016 1 commit
  31. 18 Aug, 2016 2 commits
  32. 16 Aug, 2016 2 commits
    • rmcilroy's avatar
      Revert of [Interpreter] Introduce InterpreterCompilationJob (patchset #7... · de2f16d3
      rmcilroy authored
      Revert of [Interpreter] Introduce InterpreterCompilationJob (patchset #7 id:140001 of https://codereview.chromium.org/2240463002/ )
      
      Reason for revert:
      Breaks Win64 bot
      
      Original issue's description:
      > [Interpreter] Introduce InterpreterCompilationJob
      >
      > Adds InterpreterCompilationJob as a sub-class of
      > CompilationJob, to enable off-thread bytecode
      > generation. Currently only used in
      > Interpreter::MakeBytecode.
      >
      > As part of this change, CompilationJob is modified
      > to make it less specific to optimized compilation,
      > renaming the phases as follows:
      >  - CreateGraph -> PrepareJob
      >  - OptimizeGraph -> ExecuteJob
      >  - GenerateCode -> FinalizeJob
      >
      > RegisterWeakObjectsInOptimizedCode is also moved out
      > of CompilationJob and instead becomes a static function
      > on Compiler.
      >
      > BUG=v8:5203
      >
      > Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
      > Committed: https://crrev.com/785990e9fc0dd9a9d963d25d0bed2909165e4ca9
      > Cr-Original-Commit-Position: refs/heads/master@{#38662}
      > Cr-Commit-Position: refs/heads/master@{#38668}
      
      TBR=mstarzinger@chromium.org,jkummerow@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5203
      
      Review-Url: https://codereview.chromium.org/2251673003
      Cr-Commit-Position: refs/heads/master@{#38669}
      de2f16d3
    • rmcilroy's avatar
      [Interpreter] Introduce InterpreterCompilationJob · 785990e9
      rmcilroy authored
      Adds InterpreterCompilationJob as a sub-class of
      CompilationJob, to enable off-thread bytecode
      generation. Currently only used in
      Interpreter::MakeBytecode.
      
      As part of this change, CompilationJob is modified
      to make it less specific to optimized compilation,
      renaming the phases as follows:
       - CreateGraph -> PrepareJob
       - OptimizeGraph -> ExecuteJob
       - GenerateCode -> FinalizeJob
      
      RegisterWeakObjectsInOptimizedCode is also moved out
      of CompilationJob and instead becomes a static function
      on Compiler.
      
      BUG=v8:5203
      
      Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
      Review-Url: https://codereview.chromium.org/2240463002
      Cr-Original-Commit-Position: refs/heads/master@{#38662}
      Cr-Commit-Position: refs/heads/master@{#38668}
      785990e9