1. 19 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [objects] Adjust overly aggressive over-allocation. · 9ffd1677
      Benedikt Meurer authored
      When setting up the initial map for a (class or function) constructor,
      we always over-allocate a bunch of in-object properties, in case not
      all property assignments happen as `this.prop = val` assignments in
      the constructor. However this over-allocation was a bit too aggressive
      and added a slack of 8 to each class constructor (plus a minimum of
      two, when there was no `this.prop = val` assignment). So in total this
      would yield an object with initially 40 in-object property slots in
      case of a simple class hierarchy like this:
      
      ```js
      class A {};
      class B extends A {};
      class C extends B {};
      class D extends C {};
      new D;
      ```
      
      While the slack tracking takes care of eventually shrinking the objects
      to appropriate sizes, this aggressive over-allocation is still going to
      hurt performance quite a bit in the beginning, and will also lead to
      more traffic on the minor GC for now good reason.
      
      Instead of the above, we now allocate a minimum of 2 in-object
      properties per class (in a hierarchy) and then add a slack of 8 in the
      end. Meaning for the example above we end up with 16 initial in-object
      property slots, which seems sensible.
      
      Bug: v8:8853
      Change-Id: I4a11e35a8612ceef1d776ca2f0543a26c8c2a2bf
      Reviewed-on: https://chromium-review.googlesource.com/c/1477276Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59670}
      9ffd1677
  2. 30 Jan, 2019 1 commit
    • Benedikt Meurer's avatar
      [runtime] Better instance pre-sizing with transpiled classes. · 4b9eb7f7
      Benedikt Meurer authored
      For instances created via constructors and `new` we try to pre-size
      the instances such that ideally all the data properties can be
      allocated as in-object properties (and we don't need to allocate the
      out-of-object PropertyArray backing store). This is accomplished with
      the helper of the Parser, which counts the property assignments to
      `this` in the constructor, and we use that as the starting point for
      pre-sizing logic (a mechanism called *slack tracking* is used to
      dynamically shrink the objects based on the real memory usage, and
      eventually compute the final starting size for instances of the
      individual constructors).
      
      This works well even with class hierarchies, since for a derived class
      constructor we just include the current constructor plus all the base
      constructors. I.e. with
      
      ```js
      class A {
        constructor() {
          this.x00 = null;
          this.x01 = null;
          this.x02 = null;
          this.x03 = null;
          this.x04 = null;
          this.x05 = null;
          this.x06 = null;
          this.x07 = null;
          this.x08 = null;
          this.x09 = null;
          this.x10 = null;
          this.x11 = null;
          this.x12 = null;
          this.x13 = null;
          this.x14 = null;
          this.x15 = null;
          this.x16 = null;
          this.x17 = null;
          this.x18 = null;
          this.x19 = null;
        }
      }
      
      class B extends A {
        constructor() {
          super();
        }
      }
      ```
      
      we will eventually learn that instances of `B` need 20 in-object
      properties. However this breaks with transpiled code (i.e. as
      generated via TypeScript or Babel), even when the constructors are
      properly chained.
      
      ```js
      function A() {
        this.x00 = null;
        this.x01 = null;
        this.x02 = null;
        this.x03 = null;
        this.x04 = null;
        this.x05 = null;
        this.x06 = null;
        this.x07 = null;
        this.x08 = null;
        this.x09 = null;
        this.x10 = null;
        this.x11 = null;
        this.x12 = null;
        this.x13 = null;
        this.x14 = null;
        this.x15 = null;
        this.x16 = null;
        this.x17 = null;
        this.x18 = null;
        this.x19 = null;
      }
      
      function B() {
        A.call(this);
      }
      Object.setPrototypeOf(B, A);
      ```
      
      Here we will always have 10 in-object properties for instances of
      `B` (due to the generic over-allocation logic), and the other 10
      properties have to be allocated in the out-of-object PropertyArray.
      
      This is unfortunate and actually not necessary. Instead we could just
      do the same [[Prototype]] walk on the constructor for regular function
      constructors that we perform for derived (native) class constructors.
      This CL changes that, such that we give the same treatment to transpiled
      class that we have for native classes.
      
      R=verwaest@chromium.org
      
      Bug: v8:8764, v8:8765
      Doc: https://bit.ly/v8-instance-presizing-with-transpiled-classes
      Change-Id: Iac54391e41c9a39101751a678b3a647269fb009d
      Reviewed-on: https://chromium-review.googlesource.com/c/1442643
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59214}
      4b9eb7f7
  3. 28 Jan, 2019 1 commit
  4. 26 Dec, 2018 1 commit
  5. 17 Dec, 2018 1 commit
  6. 08 Dec, 2018 1 commit
  7. 26 Nov, 2018 1 commit
  8. 01 Oct, 2018 1 commit
  9. 31 Jul, 2018 1 commit
  10. 23 Jul, 2018 1 commit
  11. 17 Jul, 2018 1 commit
  12. 26 Jun, 2018 1 commit
    • Georg Neis's avatar
      Reland "Reland "Introduce MutableHeapNumber class."" · f1c79e02
      Georg Neis authored
      This is a reland of f0bcbc90.
      A few casts were still wrong.
      
      Original change's description:
      > Reland "Introduce MutableHeapNumber class."
      >
      > This is a reland of 40ac6b18, which
      > was incorrect due to a bad merge.
      >
      > Original change's description:
      > > Introduce MutableHeapNumber class.
      > >
      > > V8 knows heap numbers and mutable heap numbers. They have
      > > difference instance types, but in C++ code we've used the
      > > same class for both (HeapNumber). Confusingly, however,
      > > IsHeapNumber would return false for mutable heap numbers,
      > > while HeapNumber::cast would succeed.
      > >
      > > This CL adds a separate class MutableHeapNumber and
      > > eliminates the confusing behavior.
      > >
      [...]
      > TBR=bmeurer@chromium.org
      > TBR=ulan@chromium.org
      >
      > Change-Id: I3af1014c949821dfac0754a3e48c65ce1bad1ad1
      > Reviewed-on: https://chromium-review.googlesource.com/1114539
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54022}
      
      Change-Id: I19a33da4b6abcd445b528a84d4f56ba1964d337b
      Reviewed-on: https://chromium-review.googlesource.com/1114100
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54027}
      f1c79e02
  13. 23 Jun, 2018 1 commit
  14. 19 Feb, 2018 1 commit
  15. 17 Feb, 2018 2 commits
  16. 12 Feb, 2018 1 commit
  17. 21 Nov, 2017 1 commit
  18. 18 Oct, 2017 1 commit
  19. 21 Sep, 2017 1 commit
  20. 01 Sep, 2017 1 commit
  21. 21 Aug, 2017 1 commit
  22. 02 Aug, 2017 1 commit
  23. 13 Jul, 2017 3 commits
  24. 29 May, 2017 1 commit
  25. 27 Feb, 2017 1 commit
  26. 23 Jan, 2017 1 commit
    • franzih's avatar
      [ast] Count index keys in AST not runtime. · 0d1e0a15
      franzih authored
      We do not want to reserve space in the backing store for index keys.
      Count index keys during creation of the BoilerplateDescription, and
      substract them for the backing store size.
      
      Correctly count index keys after encountering a property with
      a computed name during object literal creation.
      
      R=verwaest@chromium.org
      
      BUG=v8:5625
      
      Review-Url: https://codereview.chromium.org/2651523002
      Cr-Commit-Position: refs/heads/master@{#42598}
      0d1e0a15
  27. 22 Jan, 2017 1 commit
    • franzih's avatar
      [test] Check object literal backing store size. · 15623183
      franzih authored
      Property backing store size for object literals is
      the number of constant and named properties (possibly
      over-allocating for the same names).
      
      We do not reserve space in the backing store for __proto__.
      
      We do not reserve space in the backing store for index keys.
      Currently, we account for index keys in the runtime when iterating
      over the boilerplate properties. Since the boilerplate properties
      only include the properties up to the first computed property
      name, the property backing store size includes space for index keys
      if seen after the first computed property.
      
      R=verwaest@chromium.org
      
      BUG=v8:5625
      
      Review-Url: https://codereview.chromium.org/2650593002
      Cr-Commit-Position: refs/heads/master@{#42584}
      15623183
  28. 09 Jan, 2017 1 commit
  29. 06 Dec, 2016 2 commits
  30. 05 Dec, 2016 1 commit
    • gsathya's avatar
      Object · 30b564c7
      gsathya authored
      -- New JSObject for promises: JSPromise
      
      Builtins
      -- PromiseThen TFJ
      -- PromiseCreateAndSet TFJ for internal use
      -- PerformPromiseThen TFJ for internal use
      -- PromiseInit for initial promise setup
      -- SpeciesConstructor for use in PromiseThen
      -- ThrowIfNotJSReceiver for use in SpeciesConstructor
      -- AppendPromiseCallback to update FixedArray with new callback
      -- InternalPerformPromiseThen
      
      Promises.js
      -- Cleanup unused symbols
      -- Remove PerformPromiseThen
      -- Remove PromiseThen
      -- Remove PromiseSet
      -- Remove PromiseAttachCallbacks
      
      Runtime
      -- PromiseSet to set promise inobject values
      -- Refactor functions to use FixedArrays for callbacks instead of
         JSArray
      -- Runtime_PromiseStatus to return promise status
      -- Runtime_PromiseResult to return promise result
      -- Runtime_PromiseDeferred to return deferred attached to promise
      -- Runtime_PromiseRejectReactions to return reject reactions attached
         to promise
      
      This CL results in a 13.07% improvement in the promises benchmark
      (over 5 runs).
      
      BUG=v8:5343
      
      Review-Url: https://codereview.chromium.org/2536463002
      Cr-Commit-Position: refs/heads/master@{#41503}
      30b564c7
  31. 23 Jun, 2016 1 commit
  32. 26 May, 2016 1 commit
    • gsathya's avatar
      Promises: Lazily create arrays to store resolve, reject callbacks · 1d4fe002
      gsathya authored
      For the common use case of having a single resolve or reject callback,
      the callbacks are stored directly. Only when an additional callback is
      registered, we create an array to store these callbacks.
      
      There are 3 possible states for the resolve, reject symbols when we add
      a new callback --
      1) UNDEFINED -- This is the zero state where there is no callback
      registered. When we see this state, we directly attach the callbacks to
      the symbol.
      2) !IS_ARRAY -- There is a single callback directly attached to the
      symbols. We need to create a new array to store additional callbacks.
      3) IS_ARRAY -- There are multiple callbacks already registered,
      therefore we can just push the new callback to the existing array.
      
      Also, this change creates a new symbol for storing the deferred objects.
      Previously the deferred objects were stored in the callback arrays, but
      since we no longer create arrays for the initial case, we need this new
      symbol. The cctest has been updated to account for this new symbol.
      
      This patch results in a 19% improvement(over 5 runs) in the bluebird benchmark.
      
      BUG=v8:5046
      
      Review-Url: https://codereview.chromium.org/2007803002
      Cr-Commit-Position: refs/heads/master@{#36536}
      1d4fe002
  33. 15 Mar, 2016 1 commit
  34. 29 Jan, 2016 1 commit
    • jkummerow's avatar
      Introduce {FAST,SLOW}_STRING_WRAPPER_ELEMENTS · f4872f74
      jkummerow authored
      String wrappers (new String("foo")) are special objects: their string
      characters are accessed like elements, and they also have an elements
      backing store. This used to require a bunch of explicit checks like:
      
      if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) {
        /* Handle string characters */
      }
      // Handle regular elements (for string wrappers and other objects)
      obj->GetElementsAccessor()->Whatever(...);
      
      This CL introduces new ElementsKinds for string wrapper objects (one for
      fast elements, one for dictionary elements), which allow folding the
      special-casing into new StringWrapperElementsAccessors.
      
      No observable change in behavior is intended.
      
      Review URL: https://codereview.chromium.org/1612323003
      
      Cr-Commit-Position: refs/heads/master@{#33616}
      f4872f74
  35. 09 Dec, 2015 2 commits