1. 30 Jun, 2017 1 commit
    • Igor Sheludko's avatar
      [runtime] Cleanup js/prologue.js. · f79b3d4e
      Igor Sheludko authored
      This CL removes unused utils.InstallFunctions, utils.InstallGetter(),
      utils.SetFunctionName, utils.OverrideFunction and respective runtime
      functions (%FunctionSetSharedName and %FunctionRemovePrototype).
      
      This CL is one of a series of cleanup CL which are the preliminary steps for
      improving function closures creation.
      
      Bug: v8:6459
      Change-Id: I0fb5940ed628f0c1958f585411e2fca3e2038054
      Reviewed-on: https://chromium-review.googlesource.com/548037
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46336}
      f79b3d4e
  2. 29 Jun, 2017 1 commit
  3. 28 Jun, 2017 3 commits
  4. 27 Jun, 2017 2 commits
  5. 26 Jun, 2017 1 commit
  6. 23 Jun, 2017 1 commit
  7. 22 Jun, 2017 5 commits
  8. 21 Jun, 2017 2 commits
  9. 20 Jun, 2017 3 commits
  10. 19 Jun, 2017 3 commits
    • Camillo Bruni's avatar
      [literals] Migrate deprecated sub-literals on the first run · ee188afe
      Camillo Bruni authored
      It might happen that we deprecate the map of previous sub-literals if we create
      literals with the same map several times. This is usually the case for
      configuration arrays.
      
      Bug: chromium:734051
      Change-Id: I82284e5aae632286135b2092816d776d229c65af
      Reviewed-on: https://chromium-review.googlesource.com/538665Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46003}
      ee188afe
    • 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
    • bmeurer's avatar
      [objects] Relax JSBoundFunction verification. · a9b9c7ab
      bmeurer authored
      The heap verifier does certain invariant checks on JSBoundFunction
      objects, i.e. it assumes that the bound_target_function is a proper
      JSReceiver. The Deoptimizer cannot maintain this invariant, because it
      first allocates the JSBoundFunction in an invalid state and only
      afterwards fix up the state. But the GC (and thus the heap verifier)
      can observe this invalid state why materializing field values, so
      we need to relax the verification slightly.
      
      BUG=chromium:729573,chromium:732176
      R=mstarzinger@chromium.org
      
      Review-Url: https://codereview.chromium.org/2933283002
      Cr-Commit-Position: refs/heads/master@{#45988}
      a9b9c7ab
  11. 16 Jun, 2017 1 commit
  12. 15 Jun, 2017 1 commit
    • Adam Klein's avatar
      Revert "[builtins] Move most WeakMap/WeakSet code from JS to C++ builtins" · 431abca0
      Adam Klein authored
      This reverts commit 8196e102.
      
      Reason for revert: Performance regression due to hashcode lookup.
      
      Original change's description:
      > [builtins] Move most WeakMap/WeakSet code from JS to C++ builtins
      > 
      > They were already implemented mostly in C++ (only error/negative
      > cases were handled in script), so this is mostly just a cleanup.
      > Only the constructors remain in script after this CL.
      > 
      > Bug: v8:6354
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Change-Id: I5b3579337a8e33dc30d49c2da5cfd42baec697bb
      > Reviewed-on: https://chromium-review.googlesource.com/531670
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
      > Commit-Queue: Adam Klein <adamk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45924}
      
      TBR=adamk@chromium.org,cbruni@chromium.org,gsathya@chromium.org
      Bug: v8:6354, chromium:733238
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Change-Id: Ia5a741b9587886298f3ca057f6a6adeba556b8e0
      Reviewed-on: https://chromium-review.googlesource.com/537207Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45966}
      431abca0
  13. 14 Jun, 2017 3 commits
  14. 13 Jun, 2017 7 commits
    • bmeurer's avatar
      [builtins] Properly optimize Object.prototype.isPrototypeOf. · b11c557d
      bmeurer authored
      Port the baseline implementation of Object.prototype.isPrototypeOf to
      the CodeStubAssembler, sharing the existing prototype chain lookup logic
      with the instanceof / OrdinaryHasInstance implementation. Based on that,
      do the same in TurboFan, introducing a new JSHasInPrototypeChain
      operator, which encapsulates the central prototype chain walk logic.
      
      This speeds up Object.prototype.isPrototypeOf by more than a factor of
      four, so that the code
      
        A.prototype.isPrototypeOf(a)
      
      is now performance-wise on par with
      
        a instanceof A
      
      for the case where A is a regular constructor function and a is an
      instance of A.
      
      Since instanceof does more than just the fundamental prototype chain
      lookup, it was discovered in Node core that O.p.isPrototypeOf would
      be a more appropriate alternative for certain sanity checks, since
      it's less vulnerable to monkey-patching. In addition, the Object
      builtin would also avoid the performance-cliff associated with
      instanceof (due to the Symbol.hasInstance hook), as for example hit
      by https://github.com/nodejs/node/pull/13403#issuecomment-305915874.
      The main blocker was the missing performance of isPrototypeOf, since
      it was still a JS builtin backed by a runtime call.
      
      This CL also adds more test coverage for the
      Object.prototype.isPrototypeOf builtin, especially when called from
      optimized code.
      
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      BUG=v8:5269,v8:5989,v8:6483
      R=jgruber@chromium.org
      
      Review-Url: https://codereview.chromium.org/2934893002
      Cr-Commit-Position: refs/heads/master@{#45925}
      b11c557d
    • Adam Klein's avatar
      [builtins] Move most WeakMap/WeakSet code from JS to C++ builtins · 8196e102
      Adam Klein authored
      They were already implemented mostly in C++ (only error/negative
      cases were handled in script), so this is mostly just a cleanup.
      Only the constructors remain in script after this CL.
      
      Bug: v8:6354
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I5b3579337a8e33dc30d49c2da5cfd42baec697bb
      Reviewed-on: https://chromium-review.googlesource.com/531670Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45924}
      8196e102
    • 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
    • Ulan Degenbaev's avatar
      [heap] Refactor JSFunction body descriptor. · 35391e43
      Ulan Degenbaev authored
      Since code flushing is gone, we treat the code entry as a strong field.
      
      Change-Id: Idfcaf6fbfd84f7e4435b81d30a2a0e1be71ec89d
      Reviewed-on: https://chromium-review.googlesource.com/531285
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45894}
      35391e43
    • Leszek Swirski's avatar
      [runtime] Don't count profiler ticks on Code objects · 09637ab3
      Leszek Swirski authored
      With the deprecation of Crankshaft, it's no longer necessary for
      FullCodeGen to keep track of its runtime profiler ticks on the code
      object, and we can instead unify the behaviour of FCG and Ignition to
      both increment the SFI counter instead.
      
      Bug: v8:6408
      Change-Id: Idcdd673aa39af06fe15a0fc14dfda2afafb5e417
      Reviewed-on: https://chromium-review.googlesource.com/528117Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45892}
      09637ab3
    • Marja Hölttä's avatar
      [objects.h splitting] Move argument-related classes. · b490fd66
      Marja Hölttä authored
      This is an unexciting CL (doesn't make the build step situation any better)
      but enables moving FixedArray & co next.
      
      BUG=v8:5402,v8:6474
      
      Change-Id: Ia36eb3973e6242f6f68e02b9f583dc552d48422f
      Reviewed-on: https://chromium-review.googlesource.com/529168
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45889}
      b490fd66
  15. 12 Jun, 2017 1 commit
  16. 09 Jun, 2017 1 commit
  17. 08 Jun, 2017 1 commit
  18. 07 Jun, 2017 1 commit
  19. 06 Jun, 2017 1 commit
    • jgruber's avatar
      [coverage] Block coverage with support for IfStatements · b4241540
      jgruber authored
      This CL implements general infrastructure for block coverage together with
      initial support for if-statements.
      
      Coverage output can be generated in lcov format by d8 as follows:
      
      $ d8 --block-coverage --lcov=$(echo ~/simple-if.lcov) ~/simple-if.js
      $ genhtml ~/simple-if.lcov -o ~/simple-if
      $ chrome ~/simple-if/index.html
      
      A high level overview of the implementation follows:
      
      The parser now collects source ranges unconditionally for relevant AST nodes.
      Memory overhead is very low and this seemed like the cleanest and simplest
      alternative.
      
      Bytecode generation uses these ranges to allocate coverage slots and insert
      IncBlockCounter instructions (e.g. at the beginning of then- and else blocks
      for if-statements). The slot-range mapping is generated here and passed on
      through CompilationInfo, and is later accessible through the
      SharedFunctionInfo.
      
      The IncBlockCounter bytecode fetches the slot-range mapping (called
      CoverageInfo) from the shared function info and simply increments the counter.
      We don't collect native-context-specific counts as they are irrelevant to our
      use-cases.
      
      Coverage information is finally generated on-demand through Coverage::Collect.
      The only current consumer is a d8 front-end with lcov-style output, but the
      short-term goal is to expose this through the inspector protocol.
      
      BUG=v8:6000
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Review-Url: https://codereview.chromium.org/2882973002
      Cr-Commit-Position: refs/heads/master@{#45737}
      b4241540
  20. 02 Jun, 2017 1 commit