1. 17 May, 2016 1 commit
    • bmeurer's avatar
      [es6] Reintroduce the instanceof operator in the backends. · 551e0aa1
      bmeurer authored
      This adds back the instanceof operator support in the backends and
      introduces a @@hasInstance protector cell on the isolate that guards the
      fast path for the InstanceOfStub. This way we recover the ~10%
      regression on Octane EarleyBoyer in Crankshaft and greatly improve
      TurboFan and Ignition performance of instanceof.
      
      R=ishell@chromium.org
      TBR=hpayer@chromium.org,rossberg@chromium.org
      BUG=chromium:597249, v8:4447
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1980483003
      Cr-Commit-Position: refs/heads/master@{#36275}
      551e0aa1
  2. 13 May, 2016 1 commit
    • verwaest's avatar
      [runtime] Make sure that LookupIterator::OWN always performs a HIDDEN lookup as well. · c9a83150
      verwaest authored
      Hidden prototypes are merely an implementation detail. Properties on an object + hidden prototype should look like properties on the object. Hence we should always perform a hidden prototype lookup. This CL removes the option to ignore hidden prototypes to avoid bugs that leak this implementation detail.
      
      Also, the only previously valid cases were either places were we knew we didn't have a hidden prototype; or because we knew we (in the optimizing compiler) would only handle properties from the non-hidden object.The first case is already handled by directly tagging whether a receiver has a hidden prototype. In the second case we can just filter out properties from hidden prototypes.
      
      Review-Url: https://codereview.chromium.org/1975763002
      Cr-Commit-Position: refs/heads/master@{#36235}
      c9a83150
  3. 12 May, 2016 1 commit
  4. 04 May, 2016 1 commit
  5. 09 Mar, 2016 1 commit
  6. 07 Mar, 2016 1 commit
  7. 04 Mar, 2016 1 commit
  8. 03 Mar, 2016 1 commit
  9. 02 Mar, 2016 3 commits
  10. 22 Feb, 2016 1 commit
    • littledan's avatar
      Optimize @@species based on a global 'protector' cell · 7033ae51
      littledan authored
      This patch makes ArraySpeciesCreate fast in V8 by avoiding two property reads
      when the following conditions are met:
      - No Array instance has had its __proto__ reset
      - No Array instance has had a constructor property defined
      - Array.prototype has not had its constructor changed
      - Array[Symbol.species] has not been reset
      
      For subclasses of Array, or for conditions where one of these assumptions is
      violated, the full lookup of species is done according to the ArraySpeciesCreate
      algorithm. Although this is a "performance cliff", it does not come up in the
      expected typical use case of @@species (Array subclassing), so it is hoped that
      this can form a good start. Array subclasses will incur the slowness of looking
      up @@species, but their use won't slow down invocations of, for example,
      Array.prototype.slice on Array base class instances.
      
      Possible future optimizations:
      - For the fallback case where the assumptions don't hold, optimize the two
        property lookups.
      - For Array.prototype.slice and Array.prototype.splice, even if the full lookup
        of @@species needs to take place, we still could take the rest of the C++
        fastpath. However, to do this correctly requires changing the calling convention
        from C++ to JS to pass the @@species out, so it is not attempted in this patch.
      
      With this patch, microbenchmarks of Array.prototype.slice do not suffer a
      noticeable performance regression, unlike their previous 2.5x penalty.
      
      TBR=hpayer@chromium.org
      
      Review URL: https://codereview.chromium.org/1689733002
      
      Cr-Commit-Position: refs/heads/master@{#34199}
      7033ae51
  11. 19 Feb, 2016 1 commit
  12. 18 Feb, 2016 1 commit
  13. 17 Feb, 2016 2 commits
  14. 16 Feb, 2016 1 commit
  15. 15 Feb, 2016 1 commit
  16. 11 Feb, 2016 1 commit
  17. 03 Feb, 2016 1 commit
  18. 02 Feb, 2016 1 commit
    • verwaest's avatar
      [runtime] Fix integer indexed property handling · 621bdd64
      verwaest authored
      This includes 2 fixes:
      1) We didn't properly advance the holder when checking whether
      Receiver==Holder, so we'd inadvertently block loading the property if
      the first property we find is on the typed array.
      2) Reflect.get may cause any object on the prototype chain of the holder
      to be the receiver; so we need to recheck for this special state for
      each object we perform lookup on.
      
      Review URL: https://codereview.chromium.org/1651913005
      
      Cr-Commit-Position: refs/heads/master@{#33689}
      621bdd64
  19. 27 Jan, 2016 1 commit
  20. 26 Jan, 2016 1 commit
    • jarin's avatar
      Replace HeapType with a non-templated FieldType class. · cfaeb63b
      jarin authored
      This replace HeapType with a dedicated class that implements just what we need for field type tracking. In the next CL, I plan to remove FieldType::Iterator because FieldType can iterate over at most one map.
      
      The ultimate plan is to get rid of templates in types.(h|cc) and remove type-inl.h.
      
      TBR=rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/1636013002
      
      Cr-Commit-Position: refs/heads/master@{#33521}
      cfaeb63b
  21. 01 Dec, 2015 1 commit
  22. 27 Nov, 2015 1 commit
  23. 26 Oct, 2015 1 commit
  24. 23 Oct, 2015 1 commit
  25. 22 Oct, 2015 1 commit
  26. 30 Sep, 2015 2 commits
  27. 14 Jul, 2015 2 commits
  28. 10 Jul, 2015 2 commits
  29. 06 Jul, 2015 1 commit
  30. 01 Jul, 2015 1 commit
    • verwaest's avatar
      Minor performance improvements to the LookupIterator · 5c278f63
      verwaest authored
      This change changes bootstrapping semantics for intercepted global objects. Unlike before, we'll now also call into the interceptor during bootstrapping. This affects properties loaded from within the runtime, such as global.Array and global.Symbol. The embedder will need to make sure that those values are the expected values during bootstrapping.
      
      BUG=chromium:505998
      LOG=n
      
      Review URL: https://codereview.chromium.org/1220813005
      
      Cr-Commit-Position: refs/heads/master@{#29414}
      5c278f63
  31. 17 Jun, 2015 2 commits
  32. 16 Jun, 2015 1 commit
  33. 12 Jun, 2015 1 commit