1. 04 May, 2020 1 commit
  2. 03 Mar, 2020 1 commit
  3. 18 Nov, 2019 1 commit
  4. 12 Sep, 2019 2 commits
  5. 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
  6. 12 Jun, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Stricter object field verification, part 1 · 3834c637
      Seth Brenith authored
      This change adjusts object initialization order for a few classes so
      that the GC can never see those objects in an invalid, partially-
      initialized state.
      
      AccessorInfo: Just zeros out a few fields upon construction. This is the
      simplest case.
      
      FunctionTemplateInfo: Slightly changes the order in which fields are
      set, so that the Smi field is set ahead of the call to SetCallHandler,
      which can GC. Also a pretty simple case.
      
      JSListFormat, JSPluralRules, JSRelativeTimeFormat, JSSegmenter: The spec
      requires that we start with OrdinaryCreateFromConstructor, which has
      observable side effects (it fetches the prototype from the new.target).
      So we split JSObject::New in half: the first half does all of the user-
      visible things and returns a Map, which we can pass to the second half
      when we're ready to actually allocate the object.
      
      JSTypedArray: Extends the pattern from JSListFormat into Torque code:
      start with a Map and don't allocate the object until we're ready to set
      all of its properties.
      
      Bug: v8:9311
      Change-Id: Id7703e8a0727ec756c774cfbb56af787658a111a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1646844
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62123}
      3834c637
  7. 23 May, 2019 2 commits
  8. 20 May, 2019 2 commits
  9. 17 May, 2019 2 commits
  10. 15 May, 2019 1 commit
  11. 10 May, 2019 1 commit
  12. 12 Apr, 2019 1 commit
  13. 24 Mar, 2019 1 commit
  14. 20 Feb, 2019 1 commit
  15. 25 Jan, 2019 1 commit
    • Mythri's avatar
      Defer inferring language mode as far as possible · 592aeefa
      Mythri authored
      Inferring the language mode involves iterating the stack to find the
      closure. This is an expensive operation and should be done only when
      required. This cl changes the implementation to infer the language
      mode only when we can't defer it any further. Currently, we infer the
      language mode when throwing an exception or when passing this
      information to PropertyCallbackArguments.
      
      This cl also changes the language mode parameter to SetProperty
      related methods to Maybe<ShouldThrow>. We only use the language mode to
      decide if we need to throw and using ShouldThrow instead of language
      mode simplifies the code by avoiding conversions from Maybe<ShouldThrow>
      to Maybe<LanguageMode> and vice-versa.
      
      Bug: v8:8580, chromium:923820, chromium:925289
      Change-Id: I72497497f62fe0d86fcecd57b06b3183b7531f7b
      Reviewed-on: https://chromium-review.googlesource.com/c/1425912
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59094}
      592aeefa
  16. 24 Jan, 2019 1 commit
  17. 08 Jan, 2019 1 commit
  18. 26 Dec, 2018 1 commit
  19. 20 Dec, 2018 1 commit
  20. 18 Dec, 2018 1 commit
  21. 13 Nov, 2018 2 commits
    • Frank Tang's avatar
      [Intl] Cache intl objects in isolate · 7aced299
      Frank Tang authored
      Remove old code in v8::Date::DateTimeConfigurationChangeNotification
      Add code to clear date time cache object in isolate.
      
      Running benchmark
      python -u tools/run_perf.py --binary-override-path \
        out/x64.release/d8 --filter "JSTests/Strings/StringLocaleCompare" \
        test/js-perf-test/JSTests.json
      python -u tools/run_perf.py --binary-override-path \
        out/x64.release/d8 --filter "JSTests/Dates" \
        test/js-perf-test/JSTests.json
      python -u tools/run_perf.py --binary-override-path \
        out/x64.release/d8 --filter "JSTests/Numbers" \
        test/js-perf-test/JSTests.json
      
      BEFORE THE FIX:
      StringLocaleCompare-Strings(Score): 184287
      toLocaleDateString-Dates(Score): 10456
      toLocaleString-Dates(Score): 10436
      toLocaleTimeString-Dates(Score): 10700
      toLocaleString-Numbers(Score): 2935
      
      AFTER THE FIX in Patch Set 13:
      StringLocaleCompare-Strings(Score): 57470000
      toLocaleDateString-Dates(Score): 6141000
      toLocaleString-Dates(Score): 4093000
      toLocaleTimeString-Dates(Score): 6323000
      toLocaleString-Numbers(Score): 3371000
      
      Bug: chromium:901748, chromium:901747, v8:5751
      Change-Id: I7578e2ced0fe967dce6424d17f15ab806cc522be
      Reviewed-on: https://chromium-review.googlesource.com/c/1320892
      Commit-Queue: Frank Tang <ftang@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57484}
      7aced299
    • Marja Hölttä's avatar
      [iwyu] Remove include heap-inl.h -> counters.h · bd0a7fd6
      Marja Hölttä authored
      This reduces the build steps after touching counters.h from 710 to 191, thus
      detaching counters.h from the giant include cluster.
      
      BUG=v8:7490,v8:8238
      
      Change-Id: I0c7e707fb945e293f8a5604cc8da438cd35b3210
      Reviewed-on: https://chromium-review.googlesource.com/c/1329695
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57468}
      bd0a7fd6
  22. 05 Nov, 2018 1 commit
  23. 26 Oct, 2018 1 commit
  24. 24 Oct, 2018 2 commits
  25. 23 Oct, 2018 1 commit
  26. 22 Oct, 2018 1 commit
  27. 18 Oct, 2018 2 commits
  28. 17 Oct, 2018 2 commits
  29. 08 Oct, 2018 1 commit
  30. 06 Oct, 2018 2 commits
  31. 05 Oct, 2018 1 commit