1. 29 Oct, 2018 1 commit
  2. 24 Oct, 2018 1 commit
    • Caitlin Potter's avatar
      [builtins] put SetPropertyInLiteral in a code-stub · ac3f98d5
      Caitlin Potter authored
      There are several core changes in this stub:
      
      1) add a version of KeyedStoreGenericGenerator::SetPropertyInLiteral()
      which supports indexed properties directly, witthout KeyedStore
      
      2) add a code stub for SetPropertyInLiteral which uses the version
      supporting indexed properties
      
      3) Use the code stub in CloneObjectIC, rather than using the smaller
      special-cased version which does not handle Names.
      
      Item 1) involves a refactoring which adds a nice way to reuse code in
      KeyedStoreGenericAssembler, which allows deleting a bunch of copy/pasted
      code. This makes it easy to reuse the index handling in
      KeyedStoreGeneric() without adding adding a bunch more duplicated
      handling. Because of this, I consider this to be somewhat of a cleanup,
      though if the copied code is preferred, I'm happy to revert to that.
      
      Item 2) is needed for Object.fromEntries(), as it's better to not
      require falling back to the slow path if a key happens to be an Smi ---
      but this is also optional.
      
      Item 3) benefits the codebase by allowing Object.fromEntries() to use
      this fast path without calling into the runtime, and without duplicating
      code which is also used by CloneObjectIC.
      
      I am skeptical that this should affect performance significantly. I've
      run ObjectLiteralSpread tests, and the mean of scores over 100 runs is
      somewhat surprising: CloneObjectIC --- the only user of this code,
      has an increased average score, while the polyfill cases score slightly
      worse --- However, the overall changes are small and likely flukes.
      The complete processed test output is below:
      
      ```
      // Mean of 100 runs of each benchmark
      
      Babel-ObjectLiteralSpread:
      -----+---------------------------+---------------------------+-------
           | With patch                | Without patch             | diff
      Mean | 11530.87                  | 12142.92                  | -5.04%
      -----+---------------------------+---------------------------+-------
      
      BabelAndOverwrite-ObjectLiteralSpread:
      -----+---------------------------+---------------------------+-------
           | With patch                | Without patch             | diff
      Mean | 10881.41                  | 11260.81                  | -3.37%
      -----+---------------------------+---------------------------+-------
      
      ObjectAssign-ObjectLiteralSpread:
      -----+---------------------------+---------------------------+-------
           | With patch                | Without patch             | diff
      Mean | 6188.92                   | 6358.55                   | -2.67%
      -----+---------------------------+---------------------------+-------
      
      ObjectAssignAndOverwrite-ObjectLiteralSpread:
      -----+---------------------------+---------------------------+-------
           | With patch                | Without patch             | diff
      Mean | 6112.80                   | 6275.54                   | -1.61%
      -----+---------------------------+---------------------------+-------
      
      ObjectSpread-ObjectLiteralSpread:
      -----+---------------------------+---------------------------+-------
           | With patch                | Without patch             | diff
      Mean | 51942.93                  | 50713.17                  | +3.46%
      -----+---------------------------+---------------------------+-------
      
      ObjectSpreadAndOverwrite-ObjectLiteralSpread:
      -----+---------------------------+---------------------------+-------
           | With patch                | Without patch             | diff
      Mean | 51375.23                  | 50833.29                  | +2.09%
      -----+---------------------------+---------------------------+-------
      ```
      
      BUG=v8:8238, v8:8021
      R=ishell@chromium.org, jkummerow@chromium.org
      
      Change-Id: I43e102fc461ffd389b5d6810a73f86e5012d7dee
      Reviewed-on: https://chromium-review.googlesource.com/c/1277751
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56957}
      ac3f98d5
  3. 23 Oct, 2018 1 commit
  4. 22 Oct, 2018 1 commit
  5. 12 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Introduce the notion of a "current microtask". · 9f28c129
      Benedikt Meurer authored
      Change the way we start collecting async stack traces by storing the
      current microtask as a root instead of trying to make sense of the
      last frame we see. This makes it possible to use the zero cost async
      stack traces in Node.js as well (where the last JavaScript frame we
      see is not the actual async function, but some frame related to the
      main event loop usually).
      
      In addition to the benefit that it now works with Node.js, we can also
      extend the new machinery to look through (almost arbitrary) promise
      chains. For example this code snippet
      
      ```js
      (async function() {
        await Promise.resolve().then(() =>
          console.log(new Error().stack));
      })();
      ```
      
      can be made to also show the async function frame, even though at the
      point where the stack trace is collected we don't have any async
      function on the stack. But instead there's a PromiseReactionJobTask
      as "current microtask", and we can dig into the chained promise to
      see where the async execution is going to continue and eventually
      find the await promise in the chain.
      
      This also removes the removes the need to allocate `.generator_object`
      specially during scope resolution.
      
      Bug: v8:7522
      Ref: nodejs/node#11865
      Tbr: ulan@chromium.org
      Design-Document: bit.ly/v8-zero-cost-async-stack-traces
      Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203
      Reviewed-on: https://chromium-review.googlesource.com/c/1277505
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56590}
      9f28c129
  6. 11 Oct, 2018 1 commit
  7. 10 Oct, 2018 1 commit
  8. 09 Oct, 2018 1 commit
  9. 21 Sep, 2018 1 commit
  10. 20 Sep, 2018 1 commit
  11. 19 Sep, 2018 2 commits
  12. 14 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Initial Word64 support in representation selection. · 6346cdb6
      Benedikt Meurer authored
      This adds support to TurboFan's representation selection for the Word64
      representation, and makes use of that to handle indices for memory access
      and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
      etc.). These instructions had previously used Word32 as representation
      for the indices / sizes, and then internally converted it to the correct
      representation (aka Word64 on 64-bit architectures) later on, but that
      was kind of brittle, and sometimes led to weird generated code.
      
      The change thus only adds support to convert integer values in the safe
      integer range from all kinds of representations to Word64 (on 64-bit
      architectures). We don't yet handle the opposite direction and none of
      the representation selection heuristics for the numeric operations were
      changed so far. This will be done in follow-up CLs.
      
      This CL itself is supposed to be neutral wrt. functionality, and only
      serves as a starting point, and a cleanup for the (weird) implicit
      Word64 index/size handling.
      
      Bug: v8:7881, v8:8015, v8:8171
      Design-Document: http://bit.ly/turbofan-word64
      Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
      Reviewed-on: https://chromium-review.googlesource.com/1224932
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55886}
      6346cdb6
  13. 03 Sep, 2018 2 commits
    • jgruber's avatar
      [builtins] Reduce register pressure in RecordWrite · 233eeade
      jgruber authored
      Just a minor refactoring that loads parameters just prior to their
      uses to reduce register spills and restores. CSA is not smart enough
      to do this on its own.
      
      Bug: v8:6666
      Change-Id: I6d01abc35b333b2b0d99fa86daaa6ecb6afcf6c0
      Reviewed-on: https://chromium-review.googlesource.com/1201883
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55588}
      233eeade
    • jgruber's avatar
      Remove isolate parameter from RecordWrite builtin · 62766423
      jgruber authored
      The isolate can be efficiently loaded through other means: either as a
      root-relative load (if embedded builtins are enabled), or as an embedded
      external reference (i.e. the absolute pointer is included in the
      instruction stream) otherwise.
      
      The generated code should be at least as fast as previously. On x64
      (with embedded builtins):
      
      Before:
       // Register moves in prologue:
       0x7f47a6b4860a     a  488955e0       REX.W movq [rbp-0x20],rdx
       // And the load from a stack slot at each use-site.
       0x7f47a6b486f2    f2  488b7de0       REX.W movq rdi,[rbp-0x20]
      
      After:
       // Each use-site just loads a root-relative offset.
       0x7f1645fcc6ce    ee  498dbd38ffffff REX.W leaq rdi,[r13-0xc8]
      
      On ia32 (no embedded builtins), before:
       0x5c608930    10  8955f0         mov [ebp-0x10],edx
       0x5c6089fb    db  891424         mov [esp],edx
      
      After:
       0x41d0898d    8d  b80033b156     mov eax,0x56b13300
      
      Removal reduces register pressure, and frees up ebx as the root register
      on ia32.
      
      Note that the set of allocatable registers was only reduced on ia32 to
      exclude the root register.
      
      Bug: v8:6666
      Change-Id: I14e401e2823c82042c76acae10c3c935b9982993
      Reviewed-on: https://chromium-review.googlesource.com/1201586
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55587}
      62766423
  14. 31 Aug, 2018 1 commit
    • Benedikt Meurer's avatar
      [es2015] Handle proxies in GetProperty builtin. · 87199f52
      Benedikt Meurer authored
      Teach the GetProperty builtin how to perform [[Get]] on JSProxy
      instances by calling into the dedicated ProxyGetProperty builtin
      that we already use for the LOAD_IC / KEYED_LOAD_IC. This is
      important when proxies are used in places were GetProperty builtin
      is used like for example as iterables in for..of loops or in spreads.
      
      On a simple micro-benchmark like the following
      
      ```js
      const proxy = new Proxy([1, 2, 3], {
        get(target, property) { return target[property]; }
      });
      const TESTS = [
          function testForOfProxy() { for (const x of proxy) {} },
          function testSpreadProxy() { return [...proxy]; }
      ];
      
      function test(fn) {
        var result;
        for (var i = 0; i < 1e6; ++i) result = fn();
        return result;
      }
      test(x => x);
      
      for (var j = 0; j < TESTS.length; ++j) test(TESTS[j]);
      for (var j = 0; j < TESTS.length; ++j) {
        var startTime = Date.now();
        test(TESTS[j]);
        print(TESTS[j].name + ':', (Date.now() - startTime), 'ms.');
      }
      ```
      
      improves from around
      
        testForOfProxy: 1672.6 ms.
        testSpreadProxy: 1956.6 ms.
      
      to
      
        testForOfProxy: 408.4 ms.
        testSpreadProxy: 530.8 ms.
      
      on average, which corresponds to a 4-5x performance improvement, even
      for small arrays. On the ARES-6 Air benchmark this completely eliminates
      all calls to the %GetProperty runtime function, and thereby improves the
      steady state mean by 2-3%.
      
      Bug: v8:6344, v8:6557, v8:6559
      Change-Id: Ifebdaff8f3ae5899a33ce408ecd54655247f3a02
      Reviewed-on: https://chromium-review.googlesource.com/1199023Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55539}
      87199f52
  15. 20 Aug, 2018 1 commit
  16. 13 Aug, 2018 1 commit
  17. 09 Aug, 2018 2 commits
  18. 07 Aug, 2018 1 commit
  19. 06 Aug, 2018 1 commit
  20. 26 Jul, 2018 1 commit
  21. 19 Jul, 2018 1 commit
    • Leszek Swirski's avatar
      [sfi] Remove SFI function identifier field · c941f11a
      Leszek Swirski authored
      Remove the function identifier field from SharedFunctionInfo. This field
      would store one of a) the function's inferred name, b) the "builtin
      function id", or c) debug info. We remove these in turn:
      
      a) The function's inferred name is available on the ScopeInfo, so like
         the start/end position we read it off either the ScopeInfo (for
         compiled functions) or the UncompiledData (for uncompiled functions).
      
         As a side-effect, now both UncompiledData and its subclass,
         UncompiledDataWithPreparsedScope, contain a pointer field. To keep
         BodyDescriptors manageable, we introduce a SubclassBodyDescriptor
         which effectively appends two BodyDescriptors together.
      
      b) The builtin function id is < 255, so we can steal a byte from
         expected no. of properies (also <255) and store these together.
         Eventually we want to get rid of this field and use the builtin ID,
         but this is pending JS builtin removal.
      
         As a side-effect, BuiltinFunctionId becomes an enum class (for better
         storage size guarantees).
      
      c) The debug info can hang off anything (since it stores the field it
         replaces), so we can attach it to the script field instead.
      
      This saves a word on compiled function (uncompiled functions
      unfortunately still have to store it in UncompiledData).
      
      Bug: chromium:818642
      Change-Id: I8b4b3a070f0fe328aafcaeac58842d144d12d996
      Reviewed-on: https://chromium-review.googlesource.com/1138328Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54543}
      c941f11a
  22. 12 Jul, 2018 1 commit
  23. 28 Jun, 2018 1 commit
    • Ross McIlroy's avatar
      [sfi] Remove DebugInfo field in SharedFunctionInfo. · c51bcd17
      Ross McIlroy authored
      Merges DebugInfo field into the function_identifier field, storing the function
      identifier in the DebugInfo. Also moves some debugging_hints bits to the SFI flags,
      and others to the DebugInfo. Finally, changes the logic to store debugger patched
      bytecode array on the SFI instead of the DebugInfo, simplifying the logic in the
      InterpreterEntryTrampoline.
      
      BUG=chromium:818642,chromium:783853
      TBR=hpayer@chromium.org
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: If440080c0f08fac4fb96f5e18dcc0eb9b86d4821
      Reviewed-on: https://chromium-review.googlesource.com/1115819
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54081}
      c51bcd17
  24. 22 Jun, 2018 3 commits
  25. 18 Jun, 2018 1 commit
  26. 14 Jun, 2018 1 commit
  27. 07 Jun, 2018 1 commit
  28. 05 Jun, 2018 1 commit
  29. 25 May, 2018 1 commit
  30. 14 May, 2018 1 commit
  31. 11 May, 2018 1 commit
  32. 07 May, 2018 1 commit
    • jgruber's avatar
      [builtins] Convert CEntry/GetProperty/StringAdd stubs to builtins · d8131cd6
      jgruber authored
      Stubs and builtins are very similar. The main differences are that
      stubs can be parameterized and may be generated at runtime, whereas
      builtins are generated at mksnapshot-time and shipped with the snapshot
      (or embedded into the binary).
      
      My main motivation for these conversions is that we can generate
      faster calls and jumps to (embedded) builtins callees from (embedded)
      builtin callers. Instead of going through the builtins constants table
      indirection, we can simply do a pc-relative call/jump.
      
      This also unlocks other refactorings, e.g. removal of
      CallRuntimeDelayed.
      
      TBR=mlippautz@chromium.org
      
      Bug: v8:6666
      Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb
      Reviewed-on: https://chromium-review.googlesource.com/1044245Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53027}
      d8131cd6
  33. 30 Apr, 2018 1 commit
  34. 25 Apr, 2018 1 commit
    • Andreas Haas's avatar
      Reland: [refactoring] Remove the isolate from signatures of ExternalReferences · 2a3c2c73
      Andreas Haas authored
      I missed one required change which was hidden behind an #if. The fix is in
      the diff between Patch 1 and Patch 3.
      
      Original message:
      In this CL I remove the isolate from signatures of ExternalReference
      accessor functions where the isolate is not used. The uses of the
      isolate were already removed in previous CLs.
      
      Changes:
      * I split the ExternalReference list in external-reference.h into
      those which need the isolate for initialization and those which do not.
      
      * I removed the public constructors and replaced them by
        ExternalReference::Create(). The reason is to separate external
        creation more clearly from internal creation, because externally
        created ExternalReferences sometimes need redirection, whereas
        internally created ExternalReferences are just stored as they are.
        In addition, by removing the isolate from the signature of the
        public constructors, they suddenly exactly matched the interal
        constructor.
      
      * Replace all uses of the public constructors with
        ExternalReference::Create().
      
      * Remove the isolate from all call sites where necessary.
      
      
      This is a step towards making WebAssembly compilation independent of
      the isolate.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:7570
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I750c162f5d58ed32e866722b0db920f8b9bd8057
      Reviewed-on: https://chromium-review.googlesource.com/1026673Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52777}
      2a3c2c73
  35. 24 Apr, 2018 1 commit
    • Andreas Haas's avatar
      Revert "[refactoring] Remove the isolate from signatures of ExternalReferences" · 7bfed2ad
      Andreas Haas authored
      This reverts commit 44ea425a.
      
      Reason for revert: https://ci.chromium.org/buildbot/client.v8.ports/V8%20Arm%20-%20debug%20builder/13575
      
      Original change's description:
      > [refactoring] Remove the isolate from signatures of ExternalReferences
      > 
      > In this CL I remove the isolate from signatures of ExternalReference
      > accessor functions where the isolate is not used. The uses of the
      > isolate were already removed in previous CLs.
      > 
      > Changes:
      > * I split the ExternalReference list in external-reference.h into
      > those which need the isolate for initialization and those which do not.
      > 
      > * I removed the public constructors and replaced them by
      >   ExternalReference::Create(). The reason is to separate external
      >   creation more clearly from internal creation, because externally
      >   created ExternalReferences sometimes need redirection, whereas
      >   internally created ExternalReferences are just stored as they are.
      >   In addition, by removing the isolate from the signature of the
      >   public constructors, they suddenly exactly matched the interal
      >   constructor.
      > 
      > * Replace all uses of the public constructors with
      >   ExternalReference::Create().
      > 
      > * Remove the isolate from all call sites where necessary.
      > 
      > 
      > This is a step towards making WebAssembly compilation independent of
      > the isolate.
      > 
      > Bug: v8:7570
      > R=​mstarzinger@chromium.org
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da
      > Reviewed-on: https://chromium-review.googlesource.com/1018982
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52768}
      
      TBR=mstarzinger@chromium.org,ahaas@chromium.org
      
      Change-Id: I7c0d8d420f815cede23d550dee8942ac4d7791cc
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7570
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1026570Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52769}
      7bfed2ad