1. 18 Nov, 2019 1 commit
  2. 16 Oct, 2019 1 commit
  3. 11 Oct, 2019 1 commit
  4. 01 Oct, 2019 1 commit
  5. 16 Sep, 2019 1 commit
  6. 12 Sep, 2019 2 commits
  7. 10 Sep, 2019 1 commit
  8. 22 Jul, 2019 1 commit
  9. 28 Jun, 2019 1 commit
  10. 27 Jun, 2019 1 commit
  11. 21 Jun, 2019 1 commit
  12. 19 Jun, 2019 1 commit
  13. 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
  14. 12 Jun, 2019 1 commit
  15. 06 Jun, 2019 1 commit
  16. 29 May, 2019 1 commit
  17. 28 May, 2019 1 commit
    • Seth Brenith's avatar
      [intl] Avoid a temporary allocation while converting to ICU string · 734c1456
      Seth Brenith authored
      If we need to build an icu::UnicodeString for a string that is currently
      in one-byte representation, we first have to expand the string's content
      into a two-byte representation. Doing so involves allocating an array,
      which is slow. With this change, we can convert short strings on the
      stack instead to save time. The cutoff length for what counts as "short"
      is pretty arbitrary, but we believe many strings fit into an 80-column
      line. This increases the score of cdjs in JetStream 2 by 35% on my
      machine, because cdjs is basically a test of localeCompare throughput.
      
      Bug: v8:9305
      
      Change-Id: Iba081ac5a8fa7659edf06ac97ba8acf3f8328d59
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630848
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61901}
      734c1456
  18. 24 May, 2019 1 commit
  19. 23 May, 2019 3 commits
  20. 22 May, 2019 1 commit
  21. 21 May, 2019 1 commit
  22. 20 May, 2019 1 commit
  23. 17 May, 2019 1 commit
  24. 16 May, 2019 2 commits
  25. 10 May, 2019 2 commits
  26. 08 May, 2019 1 commit
  27. 07 May, 2019 1 commit
  28. 29 Apr, 2019 2 commits
  29. 19 Apr, 2019 1 commit
  30. 12 Apr, 2019 1 commit
  31. 10 Apr, 2019 1 commit
  32. 07 Mar, 2019 1 commit
  33. 04 Mar, 2019 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Remove obsolete "one byte data hint" for strings. · 683cf6f4
      Benedikt Meurer authored
      In the early days of Chrome when we used WebKit there was no support for
      ASCII strings on the C++ side, so we put a hint onto these two-byte
      strings that said "string only contains one byte data", such that
      internally in V8 when these were involved in string operations, we could
      instead create the *cheaper* one byte strings.
      
      Nowadays Blink properly supports one-byte string representations and
      this additional hint only comes with overhead, since we check it in
      quite a few places (i.e. on the hot path for string concatenation), plus
      we end up consuming more memory due to the additional string maps.
      Removing the hint also frees one bit in the InstanceType zoo for
      strings.
      
      This alone improves performance on the `bench-dom-serialize.js` test case
      by around **3%**.
      
      Tbr: mstarzinger@chromium.org
      Bug: v8:6622, v8:8834, v8:8939
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Change-Id: I0753f2859cee7b5a37b6f0da64d8ec39fcb044ff
      Doc: https://bit.ly/fast-string-concatenation-in-javascript
      Reviewed-on: https://chromium-review.googlesource.com/c/1498478
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60006}
      683cf6f4
  34. 28 Feb, 2019 1 commit