1. 27 Nov, 2017 1 commit
    • Sathya Gunasekaran's avatar
      [class] Store class fields initializer on the constructor · 4ca9d843
      Sathya Gunasekaran authored
      Previously, the class fields initializer function was stored on a
      synthetic context allocated variable. This approach had sevaral
      problems:
      
      - We didn't know that class literal had fields until after we had
      completely parsed the class literal. This meant that we had to go back
      and fix up the scope of the constructor to have this synthetic
      variable. This resulted in mismatch between parser and preparsed scope
      data.
      
      - This synthetic variable could potentially resolve to an initializer
      of an outer class.
      
      For ex:
      class X extends Object {
        c = 1;
        constructor() {
          var t = () => {
            class P extends Object {
              constructor() {
                var t = () => { super(); };
                t();
              }
            }
            super();
          }
          t();
        }
      }
      
      In this the inner class P could access the outer class X's initiliazer
      function. We would have to maintain extra metadata to make sure this
      doesn't happen.
      
      Instead this new approach uses a private symbol to store the
      initializer function on the class constructor itself.
      
      For the base constructor case, we can simply check for a bit on the
      constructor function literal to see if we need to emit code that loads
      and calls this initializer function. Therefore, we don't pay the cost
      of loading this function in case there are no class fields.
      
      For the derived constructor case, there are two possiblities:
      (a) We are in a super() call directly in the derived constructor:
      
      In this case we can do a check similar to the base constructor check,
      we can check for a bit on the derived constructor and emit code for
      loading and calling the initializer function.
      
      This is usually the common case and we don't pay any cost for not using
      class fields.
      
      (b) We are in a super() call inside an arrow function in the derived
      constructor:
      
      In this case, we /always/ emit code to load and call the initializer
      function. If the function doesn't exist then we have undefined and we
      don't call anything. Otherwise we call the function.
      
      super() can't be called twice so even if we emit code to load and call
      the initializer function multiple times, it doesn't matter because it
      would have already been an error.
      
      Bug: v8:5367
      Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88
      Reviewed-on: https://chromium-review.googlesource.com/781660
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49628}
      4ca9d843
  2. 27 Oct, 2017 1 commit
    • Adam Klein's avatar
      [ast] Move AstValue implementation into Literal · 317cf321
      Adam Klein authored
      This eliminates the AstValue class, effectively moving its
      implementation into the Literal AstNode. This should cause
      no difference in behavior, but it does signal some shifts
      in the underlying system. Biggest changes include:
      
        - Reduction in AST memory usage
        - No duplicate HeapNumbers in Ignition constant pools
        - Non-String values are allocated either at constant pool
          creation time (or at boilerplate creation time for literals),
          rather than at AstValueFactory::Internalize() time.
      
      There are a variety of test-only/debug-only changes due to these
      switches as well.
      
      Bug: v8:6984
      Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1
      Reviewed-on: https://chromium-review.googlesource.com/731111
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49013}
      317cf321
  3. 18 Oct, 2017 1 commit
  4. 15 May, 2017 1 commit
  5. 15 Feb, 2017 1 commit
  6. 10 Feb, 2017 1 commit
  7. 03 Jan, 2017 1 commit
  8. 17 Oct, 2016 1 commit
  9. 03 Oct, 2016 1 commit
    • leszeks's avatar
      [base] Optimise hashmaps with simple key equality · 306f8311
      leszeks authored
      Hashmaps with a simple key equality method (comparing pointers) don't
      need to waste cycles (and branches) comparing hash values, as the key
      comparison is cheap.
      
      This patch modifies the hashmap's MatchFun to take the hashes as well as
      the keys, thus allowing the MatchFun to ignore the hashes. This allows
      slightly cleaner generated code, especially when the MatchFun is
      inlined.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2381303002
      Cr-Commit-Position: refs/heads/master@{#39932}
      306f8311
  10. 29 Sep, 2016 1 commit
    • leszeks's avatar
      [interpreter] Use hashmap for ConstantArrayBuilder's constant map · 0134ddae
      leszeks authored
      Uses the base hashmap to store the ConstantArrayBuilder's constant map,
      which slightly improves the performance of ConstantArrayBuilder::Insert.
      
      Includes a small overload of the hashmap LookupOrInsert method, which
      allows passing in a value creation function instead of just default
      initialising new values.
      
      On Octane's codeload, this gives (on my machine) a 0.27% improvement,
      which doesn't sound like a lot but I guess every little helps.
      
      Review-Url: https://codereview.chromium.org/2336553002
      Cr-Commit-Position: refs/heads/master@{#39883}
      0134ddae
  11. 20 Sep, 2016 1 commit
  12. 18 Aug, 2016 1 commit
  13. 10 Aug, 2016 1 commit
  14. 05 Aug, 2016 1 commit
  15. 25 Jul, 2016 1 commit
  16. 21 Mar, 2016 1 commit
    • oth's avatar
      [interpreter] Add support for scalable operands. · 48d082af
      oth authored
      This change introduces wide prefix bytecodes to support wide (16-bit)
      and extra-wide (32-bit) operands. It retires the previous
      wide-bytecodes and reduces the number of operand types.
      
      Operands are now either scalable or fixed size. Scalable operands
      increase in width when a bytecode is prefixed with wide or extra-wide.
      
      The bytecode handler table is extended to 256*3 entries. The
      first 256 entries are used for bytecodes with 8-bit operands,
      the second 256 entries are used for bytecodes with operands that
      scale to 16-bits, and the third group of 256 entries are used for
      bytecodes with operands that scale to 32-bits.
      
      LOG=N
      BUG=v8:4747,v8:4280
      
      Review URL: https://codereview.chromium.org/1783483002
      
      Cr-Commit-Position: refs/heads/master@{#34955}
      48d082af
  17. 26 Feb, 2016 1 commit
  18. 02 Feb, 2016 1 commit
    • oth's avatar
      [interpreter] Move temporary register allocator into own file. · ef93854a
      oth authored
      Moves the temporary register allocator out of the bytecode array
      builder into TemporaryRegisterAllocator class and adds unittests.
      Particular must be taken around the translation window boundary
      motivating the addition of tests.
      
      Also adds a Clear() method to IdentityMap() which is called by
      the destructor. This allows classes to hold an IdentityMap if
      they are zone allocated. Classes must call Clear() before the zone
      is re-cycled or face v8 heap corruption.
      
      BUG=v8:4280,v8:4675
      LOG=N
      
      Review URL: https://codereview.chromium.org/1651133002
      
      Cr-Commit-Position: refs/heads/master@{#33686}
      ef93854a
  19. 20 Jan, 2016 1 commit
  20. 05 Jan, 2016 1 commit
    • oth's avatar
      [Interpreter] Add support for jumps using constants with wide operands. · 8109f63f
      oth authored
      This increases the size of addressable constant pool entries for jumps
      to match other bytecodes using operands indexing the constant pool.
      
      This change also introduces reservations for constant pool entries.
      Reservations are used for forward jumps to ensure a constant pool entry
      will be available when the jump target (label) is bound and the jump is
      patched up in the bytecode array.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1546683002
      
      Cr-Commit-Position: refs/heads/master@{#33125}
      8109f63f