1. 22 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Introduce dedicated GetTemplateObject bytecode. · 79ac69b8
      Benedikt Meurer authored
      Tagged templates were previously desugared during parsing using some
      combination of runtime support written in JavaScript and C++, which
      prevented some optimizations from happening, namely the constant folding
      of the template object in TurboFan optimized code. This CL adds a new
      bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
      node), which represents the abstract operation in the ES6 specification
      and allows TurboFan to simply constant-fold template objects at compile
      time (which is explicitly supported by the specification).
      
      This also pays down some technical debt by removing the template.js
      runtime support and therefore should reduce the size of the native
      context (snapshot) a bit.
      
      With this change in-place the ES6 version microbenchmark in the
      referenced tracking bug is now faster than the transpiled Babel
      code, it goes from
      
        templateStringTagES5: 4552 ms.
        templateStringTagES6: 14185 ms.
        templateStringTagBabel: 7626 ms.
      
      to
      
        templateStringTagES5: 4515 ms.
        templateStringTagES6: 7491 ms.
        templateStringTagBabel: 7639 ms.
      
      which corresponds to a solid 45% reduction in execution time. With some
      further optimizations the ES6 version should be able to outperform the
      ES5 version. This micro-benchmark should be fairly representative of the
      six-speed-templatestringtag-es6 benchmark, and as such that benchmark
      should also improve by around 50%.
      
      Bug: v8:6819,v8:6820
      Tbr: mlippautz@chromium.org
      Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
      Reviewed-on: https://chromium-review.googlesource.com/677462Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarCaitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48126}
      79ac69b8
  2. 13 Sep, 2017 1 commit
  3. 11 Sep, 2017 2 commits
  4. 08 Sep, 2017 1 commit
  5. 07 Sep, 2017 1 commit
  6. 30 Aug, 2017 2 commits
  7. 23 Aug, 2017 1 commit
  8. 16 Aug, 2017 1 commit
  9. 03 Aug, 2017 1 commit
  10. 02 Aug, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] move breakpoint management to native · cd9e86a5
      Alexey Kozyatinskiy authored
      My goal was to move breakpoint API to native with minimal changes around, so on inspector side we use v8::debug::BreakpointId instead of String16, on v8::internal::Debug we use i::BreakPoint object instead of break point object created inside of debug.js.
      
      There are a lot of opportunities how we can improve breakpoints (at least we can avoid some of linear lookups to speedup implementation) but I think that as first step we need to remove mirrors/debug.js APIs.
      
      Drive by: debugger-script.js and usage of debugger context in inspector code base.
      
      R=yangguo@chromium.org,jgruber@chromium.org,clemensh@chromium.org
      
      Bug: v8:5510,chromium:652939
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I0b17972c39053dd4989bbe26db2bb0b88ca378f7
      Reviewed-on: https://chromium-review.googlesource.com/593156Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47091}
      cd9e86a5
  11. 27 Jul, 2017 1 commit
  12. 24 Jul, 2017 2 commits
  13. 13 Jul, 2017 1 commit
  14. 11 Jul, 2017 1 commit
  15. 10 Jul, 2017 2 commits
    • Benedikt Meurer's avatar
      [builtins] Port Map and Set iterators to CodeStubAssembler. · 3b84cbfe
      Benedikt Meurer authored
      This is the next step towards faster Map and Set iteration. It
      introduces the appropriate instance types for Map and Set
      iterators (following the pattern for Array iterators) and migrates
      the following builtins to the CodeStubAssembler:
      
        - Set.prototype.entries
        - Set.prototype.values
        - Map.prototype.entries
        - Map.prototype.keys
        - Map.prototype.values
        - %SetIteratorPrototype%.next
        - %MapIteratorPrototype%.next
      
      This already provides a significant performance boost for regular
      for-of iteration of Sets and Maps, by a factor of 5-10 depending
      on the input. The final step will be to inline some fast-paths
      into TurboFan.
      
      Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
      intrinsics and runtime functions.
      
      TBR=jgruber@chromium.org
      
      Bug: v8:6344, v8:6571, chromium:740122
      Change-Id: I3ab0ee49e2afe8d4295707a5ecbd51adda621918
      Reviewed-on: https://chromium-review.googlesource.com/563626
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46497}
      3b84cbfe
    • Michael Achenbach's avatar
      Revert "[builtins] Port Map and Set iterators to CodeStubAssembler." · 5a6e24e9
      Michael Achenbach authored
      This reverts commit 3f22832b.
      
      Reason for revert: Layout tests:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16849
      
      Original change's description:
      > [builtins] Port Map and Set iterators to CodeStubAssembler.
      > 
      > This is the next step towards faster Map and Set iteration. It
      > introduces the appropriate instance types for Map and Set
      > iterators (following the pattern for Array iterators) and migrates
      > the following builtins to the CodeStubAssembler:
      > 
      >   - Set.prototype.entries
      >   - Set.prototype.values
      >   - Map.prototype.entries
      >   - Map.prototype.keys
      >   - Map.prototype.values
      >   - %SetIteratorPrototype%.next
      >   - %MapIteratorPrototype%.next
      > 
      > This already provides a significant performance boost for regular
      > for-of iteration of Sets and Maps, by a factor of 5-10 depending
      > on the input. The final step will be to inline some fast-paths
      > into TurboFan.
      > 
      > Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
      > intrinsics and runtime functions.
      > 
      > Bug: v8:6571, chromium:740122
      > Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf
      > Reviewed-on: https://chromium-review.googlesource.com/563399
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46492}
      
      TBR=jgruber@chromium.org,bmeurer@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:6571, chromium:740122
      Change-Id: Iadb48d72e3b85ec8ad880e50ab7912c5502caf07
      Reviewed-on: https://chromium-review.googlesource.com/564419Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46495}
      5a6e24e9
  16. 08 Jul, 2017 1 commit
    • Benedikt Meurer's avatar
      [builtins] Port Map and Set iterators to CodeStubAssembler. · 3f22832b
      Benedikt Meurer authored
      This is the next step towards faster Map and Set iteration. It
      introduces the appropriate instance types for Map and Set
      iterators (following the pattern for Array iterators) and migrates
      the following builtins to the CodeStubAssembler:
      
        - Set.prototype.entries
        - Set.prototype.values
        - Map.prototype.entries
        - Map.prototype.keys
        - Map.prototype.values
        - %SetIteratorPrototype%.next
        - %MapIteratorPrototype%.next
      
      This already provides a significant performance boost for regular
      for-of iteration of Sets and Maps, by a factor of 5-10 depending
      on the input. The final step will be to inline some fast-paths
      into TurboFan.
      
      Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
      intrinsics and runtime functions.
      
      Bug: v8:6571, chromium:740122
      Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf
      Reviewed-on: https://chromium-review.googlesource.com/563399
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46492}
      3f22832b
  17. 07 Jul, 2017 1 commit
  18. 06 Jul, 2017 1 commit
  19. 03 Jul, 2017 1 commit
  20. 30 Jun, 2017 2 commits
    • Mathias Bynens's avatar
      [elements] Rename FAST elements kinds · 26c00f4a
      Mathias Bynens authored
      The `FAST_` prefix doesn’t make much sense — they’re all just different cases
      with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
      vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.
      
      This patch renames the FAST elements kinds as follows:
      
      - e.g. FAST_ELEMENTS => PACKED_ELEMENTS
      - e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS
      
      The following exceptions are left intact, for lack of a better name:
      
      - FAST_SLOPPY_ARGUMENTS_ELEMENTS
      - SLOW_SLOPPY_ARGUMENTS_ELEMENTS
      - FAST_STRING_WRAPPER_ELEMENTS
      - SLOW_STRING_WRAPPER_ELEMENTS
      
      This makes it easier to reason about elements kinds, and less confusing to
      explain how they’re used.
      
      R=jkummerow@chromium.org, cbruni@chromium.org
      BUG=v8:6548
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
      Reviewed-on: https://chromium-review.googlesource.com/556032Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46361}
      26c00f4a
    • Marja Hölttä's avatar
      [parser] Skipping inner funcs: Associate data to SharedFunctionInfo, not Script. · 937b5011
      Marja Hölttä authored
      This way, each lazy function needs to handle only the data relevant to
      itself. This reduced data handling overheads.
      
      Other changes:
      
      1) Don't deserialize the data; once it's on the heap, it can stay there. Lazy
      function compilation is only done in the main thread.
      
      2) Separate ProducedPreParsedScopeData and ConsumedPreParsedScopeData. It's clearer, because:
      
      - The data looks fundamentally different when we're producing it and when we're
        consuming it.
      
      - Cleanly separates the operations we can do in the "producing phase" and in the
        "consuming phase".
      
      Bug: v8:5516
      Change-Id: I6985a6621f71b348a55155724765624b5d5f7c33
      Reviewed-on: https://chromium-review.googlesource.com/528094
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46347}
      937b5011
  21. 29 Jun, 2017 1 commit
  22. 27 Jun, 2017 1 commit
  23. 20 Jun, 2017 1 commit
  24. 14 Jun, 2017 1 commit
  25. 13 Jun, 2017 1 commit
  26. 12 Jun, 2017 1 commit
  27. 06 Jun, 2017 2 commits
    • Igor Sheludko's avatar
      [parser] Introduce SharedFunctionInfo::has_shared_name(). · 9a2c18f5
      Igor Sheludko authored
      Properly propagate the fact that the function has a statically known name from
      parser to SharedFunctionInfo objects. The empty string that has been set as
      name before this CL does not help to distinguish cases like:
        var o1 = { ''(){} };
        var o1 = { [foo()](){} };
      or
        var o2 = { get ''(){} };
        var o2 = { get [foo()](){} };
      
      This is a preliminary step for using different layouts for closure objects with
      and without computed names.
      
      TBR=bmeurer@chromium.org, marja@chromium.org
      
      Bug: v8:6459
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I10afa6f4bda7881c3714711a75f720f83c1d875d
      Reviewed-on: https://chromium-review.googlesource.com/522073
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45744}
      9a2c18f5
    • 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
  28. 29 May, 2017 1 commit
  29. 23 May, 2017 3 commits
  30. 28 Apr, 2017 1 commit
  31. 27 Apr, 2017 1 commit
    • cbruni's avatar
      [runtime] Ensure slow properties for simple {__proto__:null} literals. · 3f73fecb
      cbruni authored
      With this CL we reduce the difference between directly using a null prototype
      in a literal or using Object.create(null).
      - The EmitFastCloneShallowObject builtin now supports cloning slow
        object boilerplates.
      - Unified behavior to find the matching Map and instantiating it for
        Object.create(null) and literals with a null prototype.
      - Cleanup of literal type parameter of CompileTimeValue, now in sync with
        ObjectLiteral flags.
      
      Review-Url: https://codereview.chromium.org/2445333002
      Cr-Commit-Position: refs/heads/master@{#44941}
      3f73fecb
  32. 18 Apr, 2017 1 commit