1. 14 Jun, 2017 2 commits
  2. 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
  3. 12 Jun, 2017 1 commit
  4. 09 Jun, 2017 1 commit
  5. 08 Jun, 2017 1 commit
  6. 07 Jun, 2017 1 commit
  7. 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
  8. 02 Jun, 2017 1 commit
  9. 31 May, 2017 1 commit
  10. 30 May, 2017 2 commits
  11. 29 May, 2017 3 commits
  12. 26 May, 2017 1 commit
  13. 23 May, 2017 6 commits
  14. 22 May, 2017 2 commits
    • Michael Lippautz's avatar
      [heap] MinorMC: Identify unmodified global handles on the fly · 652c9522
      Michael Lippautz authored
      For the Scavenger we require a first pass over global handles for identifying
      unmodified nodes because the Scavenger might have already written forwarding
      pointers during scanning, making it hard to perform the proper checks.
      
      The minor MC does not mutate the object graph during marking and can thus merge
      this phase into the regular phase executed during marking roots.
      
      Furthermore, moves processing into the parallel marking phase of the minor MC
      collector.
      
      Bug: chromium:720477, chromium:651354
      Change-Id: Id33552124264e3ab0bdf34d22ac30c19c1522707
      Reviewed-on: https://chromium-review.googlesource.com/509550
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45461}
      652c9522
    • Ross McIlroy's avatar
      [Heap] Remove code flushing. · f5d0df35
      Ross McIlroy authored
      Only FullCodegen code ever gets flushed by code flushing. Since we are
      deprecating the old pipeline, the added complexity introduced by code
      flushing is no longer worth it. This CL removes it (but keeps code aging,
      which is used to unlink SFIs from the compilation cache).
      
      BUG=v8:6389,v8:6379,v8:6409
      
      Change-Id: I90de113a101f86dbeaaf0511c61a090ef12aa365
      Reviewed-on: https://chromium-review.googlesource.com/507388
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45446}
      f5d0df35
  15. 19 May, 2017 1 commit
  16. 18 May, 2017 3 commits
  17. 17 May, 2017 3 commits
  18. 16 May, 2017 2 commits
    • Leszek Swirski's avatar
      [ignition] Change --trace-ignition to a runtime flag · 4becbe34
      Leszek Swirski authored
      Generate the code (extra runtime calls) for --trace-ignition support at
      compile time, based on a #define (similar to TRACE_MAPS). Then check for
      --trace-ignition at run-time when deciding whether to actually print
      anything. This should make --trace-ignition less painful to use.
      
      Note that --trace-igition is disabled by default, even on debug builds.
      It has to be enabled with the gn arg "v8_enable_trace_ignition=true"
      
      As a drive-by, TRACE_MAPS is renamed to V8_TRACE_MAPS, for consistency,
      and SFI unique index (needed both by --trace-ignition and --trace-maps)
      is cleaned up to be behind another #define.
      
      Change-Id: I8dd0c62d0e6b7ee9c75541d45eb729dc03acbee9
      Reviewed-on: https://chromium-review.googlesource.com/506203
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45346}
      4becbe34
    • Tobias Tebbi's avatar
      [runtime] avoid trim/grow loop when adding and removing one element · cd33ec55
      Tobias Tebbi authored
      We currently grow the backing store to (old_capacity*1.5)+16 if we exceed capacity, 
      but shrink the capacity to the current length when 2*length <= capacity.
      For short arrays (up to length 32), this can lead to a copy on every operation when using push/pop or push/shift.
      
      Example:
      Array of length 32, capacity 32
      push
      Array grown to length 33, capacity 32*1.5+16 = 64
      pop
      Array trimmed to length 32, capacity 32 because 2*32 <= 64
      ...
      
      This CL leaves additional slag space when calling pop and restricts the trimming to backing stores with at least 16 elements to prevent excessive re-trimming on short arrays.
      
      Bug: 
      Change-Id: I9dd13e5e2550c7ac819294c8e29f04c8855e02a4
      Reviewed-on: https://chromium-review.googlesource.com/502911
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45324}
      cd33ec55
  19. 15 May, 2017 1 commit
    • Marja Hölttä's avatar
      Revert "[objects.h splitting] Move Map and related classes." · cc2c1144
      Marja Hölttä authored
      This reverts commit 7be0159e.
      
      Reason for revert: Broke node by generating a broken debug-support.cc
      
      Original change's description:
      > [objects.h splitting] Move Map and related classes.
      > 
      > BUG=v8:5402
      > 
      > Change-Id: I64fae0a0271eb0f1b71f4ec5d9bd5d22deb1cf59
      > Reviewed-on: https://chromium-review.googlesource.com/502808
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Marja Hölttä <marja@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45305}
      
      TBR=marja@chromium.org,mstarzinger@chromium.org,jarin@chromium.org,ishell@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5402
      
      Change-Id: Ifa65537447eb0a1ef947b9d0dae6f07a8b150968
      Reviewed-on: https://chromium-review.googlesource.com/506011Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45307}
      cc2c1144