1. 30 Oct, 2019 1 commit
  2. 16 Oct, 2019 1 commit
  3. 09 Oct, 2019 1 commit
  4. 01 Oct, 2019 1 commit
  5. 26 Sep, 2019 1 commit
  6. 17 Sep, 2019 1 commit
  7. 16 Sep, 2019 1 commit
  8. 13 Sep, 2019 2 commits
  9. 12 Sep, 2019 3 commits
  10. 04 Sep, 2019 1 commit
  11. 27 Aug, 2019 1 commit
  12. 26 Aug, 2019 1 commit
  13. 23 Aug, 2019 1 commit
  14. 22 Aug, 2019 1 commit
    • Sathya Gunasekaran's avatar
      Revert "[ic] Fix KeyedLoadIC for ArrayIndex access" · 3bd0dc18
      Sathya Gunasekaran authored
      This reverts commit 5c59ba4f.
      
      Reason for revert: requires more thinking 
      
      Original change's description:
      > [ic] Fix KeyedLoadIC for ArrayIndex access
      > 
      > Previously, without support for converting strings to numbers we'd
      > switch to megamorphic state and go to the runtime always to do the
      > conversion causing a performance cliff.
      > 
      > This patch improves the following js-perf-test scores:
      > Object-Lookup-String-Constant-BytecodeHandler: 4.25%
      > Object-Lookup-Index-String-BytecodeHandler: 5.41%
      > 
      > Bug: v8:9449
      > Change-Id: I63787fa84373fc946f1304b0141e48a52a1b4bcb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690953
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63293}
      
      TBR=mythria@chromium.org,jyan@ca.ibm.com,gsathya@chromium.org,leszeks@chromium.org,ishell@chromium.org,verwaest@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9449
      Change-Id: I6b6ad5901175c2e6bbd7516b13e91471adb5776d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1765532Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63347}
      3bd0dc18
  15. 20 Aug, 2019 1 commit
  16. 29 Jul, 2019 1 commit
    • Jakob Gruber's avatar
      [regexp] Restructure fast path check logic · c6b1ef0e
      Jakob Gruber authored
      Prior to this CL, the regexp fast path check is stricter than it
      needs to be. For example, adding any arbitrary property on the regexp
      prototype would move the execution of all regexp builtins in the same
      context onto the slow path. This actually happens in the real world:
      popular web frameworks commonly monkey-patch builtin prototypes to add
      functionality.
      
      The intent of this CL is to widen the fast path for regexp builtins s.t.
      modifications of the prototype that do not conflict with our
      requirements stay on the fast path.
      
      This is done by extending the current fast path check with an
      additional step. If checking the prototype map identity or
      relevant prototype property constness fails, we now compare the actual
      value of all relevant properties against the expected value. If these
      match, the prototype can be considered fast.
      
      The new step as described in the previous paragraph is part of the
      permissive fast path check (BranchIfFastRegExp_Permissive). The strict
      variant (BranchIfFastRegExp_Strict) is also still required by a few
      spots. We should refactor these to also allow the permissive check in
      follow-up work.
      
      Bug: v8:5577,chromium:977382
      Change-Id: I69b2244e68ccfbd00edf17fc326aa4b5f5d089fa
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706056
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62948}
      c6b1ef0e
  17. 18 Jul, 2019 1 commit
  18. 11 Jul, 2019 1 commit
    • Mythri A's avatar
      [runtime] Remove try_fast path from GetOwnPropertyNames builtin · b048429e
      Mythri A authored
      GetOwnPropertyNameTryFast uses ENUMERABLE_STRINGS filter to trigger fast
      path in KeyAccumulator::GetKeys conditionally when all properties on the
      receiver are enumerable. It is not easy to verify if all properties are
      enumerable and the current check is incorrect in some cases.
      For ex: when we have non-enumerable properties when we have elements on
      the receiver. This cl removes this try_fast path from the builtin. This
      could impact performance. The long term fix for this would be to fix
      KeyAccumulator::GetKeys to use fast path for more cases.
      
      
      Bug: chromium:977870
      Change-Id: Iecde730739c2c452ffa0d893d0d1b3612a45d1b2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679499Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62649}
      b048429e
  19. 24 Jun, 2019 1 commit
    • Mathias Bynens's avatar
      [objects] Rename JSValue to JSPrimitiveWrapper · e428dfd7
      Mathias Bynens authored
      We currently use the class name “JSValue” for JSObjects that wrap
      primitive values. This name is a common source of confusion. This patch
      switches to a name that’s more clear.
      
      In addition to manual tweaks, the patch applies the following mechanical
      global replacements:
      
      before                          | after
      --------------------------------|--------------------------------------
      if_valueisnotvalue              | if_valueisnotwrapper
      if_valueisvalue                 | if_valueiswrapper
      js_value                        | js_primitive_wrapper
      JS_VALUE_TYPE                   | JS_PRIMITIVE_WRAPPER_TYPE
      JSPrimitiveWrapperType          | JSPrimitiveWrapper type
      jsvalue                         | js_primitive_wrapper
      JSValue                         | JSPrimitiveWrapper
      _GENERATED_JSVALUE_FIELDS       | _GENERATED_JSPRIMITIVE_WRAPPER_FIELDS
      
      Change-Id: I9d9edea784eab6067b013e1f781e4db2070f807c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672942Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62337}
      e428dfd7
  20. 17 Jun, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Stricter object field verification, part 2 · 15ea19db
      Seth Brenith authored
      This change removes the special case in the Torque compiler for types
      that descend from JSObject: they will no longer get implicit
      "| Undefined" appended to their types for verification purposes. It
      removes any additional custom verification steps in objects-debug that
      are made redundant by that change.
      
      In order to do so safely, I categorized all cases where we were
      implicitly adding "| Undefined" to the field type, as follows:
      
      1. Classes that aren't using the generated verifier function (we should
         probably revisit these, but for now we at least know they're safe):
         - JSGlobalObject
         - JSFinalizationGroup
         - JSFinalizationGroupCleanupIterator
      
      2. Classes where the existing verifier is already at least as strict as
         what we would get after removing the implicit "| Undefined":
         - JSDate
         - JSPromise
         - JSRegExp
         - JSRegExpStringIterator
         - WasmMemoryObject
         - JSWeakRef
         - JSStringIterator
         - WasmExceptionObject
         - JSListFormat (fixed in part 1)
         - JSPluralRules (fixed in part 1)
         - JSRelativeTimeFormat (fixed in part 1)
         - JSSegmenter (fixed in part 1)
         - JSArrayBufferView (fixed in part 1)
         - JSTypedArray (fixed in part 1)
      
      3. Classes where, to the best of my knowledge based on code inspection,
         we already initialize the object correctly to pass the new stricter
         generated verifier:
         - JSFunction
         - JSArrayIterator
         - JSMessageObject
         - JSBoundFunction
         - JSAsyncFromSyncIterator
         - WasmModuleObject
         - JSAsyncFunctionObject
      
      4. Classes that needed some adjustment to their initialization order to
         avoid exposing uninitialized state to the GC:
         - JSArray (only in Factory::NewJSArray; Runtime_NewArray and
                    CodeStubAssembler::AllocateJSArray already behave fine)
         - WasmTableObject
         - JSDateTimeFormat
         - JSNumberFormat
         - JSCollator
         - JSV8BreakIterator
         - JSLocale
         - JSSegmentIterator
         - JSModuleNamespace
      
      5. Classes that had incorrect type definitions in Torque:
         - WasmGlobalObject (category 4 after correction)
      
      6. Classes that weren't fully initialized due to bugs:
         - JSGeneratorObject
         - JSAsyncGeneratorObject
      
      Bug: v8:9311
      Change-Id: I99ab303d3352423f50a3d0abb6eb0c9b463e7552
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1654980
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62228}
      15ea19db
  21. 31 May, 2019 1 commit
    • Benedikt Meurer's avatar
      [map] Remove Map::has_hidden_prototype(). · 2f379994
      Benedikt Meurer authored
      The `FunctionTemplate::SetHiddenPrototype()` API was removed in a
      previous CL, after being deprecated since beginning of the year. This
      removes all the logic behind it, leaving us with just the special case
      of the JSGlobalProxy which has the JSGlobalObject as its hidden prototype.
      
      This gives us back one bit in `Map::bit_field2` and removes quite a bit
      of complexity from the code base (especially due to previous work from
      verwaest@ in this area).
      
      Bug: v8:9267
      Change-Id: Id04b59686212fe35a63c9451aa3e045f0766b9cc
      Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619752
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61938}
      2f379994
  22. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  23. 21 May, 2019 1 commit
  24. 20 May, 2019 2 commits
  25. 29 Apr, 2019 1 commit
    • Benedikt Meurer's avatar
      [runtime] Optimize general object spread. · 4995c85f
      Benedikt Meurer authored
      This adds a new %_CopyDataProperties intrinsic, that reuses most of the
      existing machinery that we already have in place for Object.assign() and
      computed property names in object literals. This speeds up the general
      case for object spread (where the spread is not the first item in an
      object literal) and brings it on par with Object.assign() at least - in
      most cases it's significantly faster than Object.assign().
      
      In the test case [1] referenced from the bug, the performance goes from
      
        objectSpreadLast: 3624 ms.
        objectAssignLast: 1938 ms.
      
      to
      
        objectSpreadLast: 646 ms.
        objectAssignLast: 1944 ms.
      
      which corresponds to a **5-6x performance boost**, making object spread
      faster than Object.assign() in general.
      
      Drive-by-fix: This refactors the Object.assign() fast-path in a way that
      it can be reused appropriately for object spread, and adds another new
      builtin SetDataProperties, which does the core of the Object.assign()
      work. We can teach TurboFan to inline Object.assign() based on the new
      SetDataProperties builtin at some later point to further optimize
      Object.assign().
      
      [1]: https://gist.github.com/bmeurer/0dae4a6b0e23f43d5a22d7c91476b6c0
      
      Bug: v8:9167
      Change-Id: I57bea7a8781c4a1e8ff3d394873c3cd4c5d73834
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587376Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61100}
      4995c85f
  26. 31 Jan, 2019 1 commit
  27. 24 Jan, 2019 1 commit
  28. 19 Dec, 2018 1 commit
  29. 18 Dec, 2018 1 commit
    • Mythri's avatar
      Fix ObjectToString builtin to work for subclasses · 2ea00908
      Mythri authored
      When we call ObjectToString on JSValues we only looked at string tags
      on the prototype map of the JSValue's value type and do not check the
      tags on the JSValue's prototype chain which may be non-trivial if
      subclassing is involved. For ex: if we have a class Test extend Number,
      we only looked for tags on the Number prototype and not on the Test
      prototype. This cl fixes the builtin to also check for these cases.
      
      
      Bug: v8:7706
      Change-Id: I9f0e3bb6499646bf27b92bf4fb4e9014f6efa56b
      Reviewed-on: https://chromium-review.googlesource.com/c/1378176Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58338}
      2ea00908
  30. 24 Nov, 2018 1 commit
  31. 22 Nov, 2018 1 commit
  32. 21 Nov, 2018 2 commits
  33. 26 Oct, 2018 1 commit
  34. 16 Oct, 2018 1 commit
  35. 08 Oct, 2018 1 commit