1. 19 Nov, 2020 1 commit
  2. 27 Oct, 2020 1 commit
    • Mike Stanton's avatar
      [TurboFan] Provide concurrent access to feedback vector · 2288b1f6
      Mike Stanton authored
      This CL provides synchronized get/set to feedback vector slots.
      The FeedbackNexus is set up to use order preserving reads when used
      on the background thread, and a lock to ensure coherent read
      of information for ICKinds with two slots. The main thread takes
      the lock on sets.
      
      This test provides patterns to be followed by concurrent TurboFan.
      
      We don't yet access the FeedbackVector on the background thread.
      This CL only makes it safe to do so. The next step will come when
      the optimizing compiler begins to query the the vector from the
      background thread. Currently, with --concurrent-inlining turned on
      this is done in bytecode serialization on the main thread. Without
      concurrent inlining, it's also done on the main thread, in both
      cases using the FeedbackNexus.
      
      Bug: v8:7790
      Change-Id: I49d8b8031190f91a0da1c24f375b6b6d8a9fe038
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2276210
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70797}
      2288b1f6
  3. 05 Oct, 2020 1 commit
  4. 04 Mar, 2020 1 commit
  5. 26 Nov, 2019 1 commit
    • Jakob Kummerow's avatar
      More LookupIterator fixes after r65078 · 3ac7a3e5
      Jakob Kummerow authored
      (1) One more place in ic.cc must guard against "lookup->name()" calls
      when the LookupIterator might be in indexed mode.
      
      (2) Rather than burdening LookupIterator users with specifying
      "kGuaranteedNoTypedArray", we can do the corresponding calculation in
      the LookupIterator itself, which makes it robust towards any callers
      that haven't been updated (specifically, in Object.values).
      
      Bug: chromium:1027461,chromium:1028213
      Change-Id: I76b5d08e309fc2a694955b537adbeb5a30e681f7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1936474Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65177}
      3ac7a3e5
  6. 20 Nov, 2019 1 commit
  7. 15 Nov, 2019 1 commit
  8. 16 Oct, 2019 1 commit
  9. 11 Oct, 2019 1 commit
  10. 17 Sep, 2019 1 commit
  11. 02 Sep, 2019 1 commit
  12. 28 Aug, 2019 1 commit
    • Z Nguyen-Huu's avatar
      Add new nonextensible element kinds · 1f4bec27
      Z Nguyen-Huu authored
      Currently the backing store and elements kind might not aligned aka
      backing store can be dictionary where elements kind is frozen/sealed
      element kinds or the other way around. The reason is that
      Object.preventExtensions change elements kind to DICTIONARY while
      Object.seal/freeze change elements kind to SEALED/FROZEN element kind.
      Apply both these operations can lead to that problem as in
      chromium:992914
      
      To solve this issue, we avoid Object.preventExtensions to change backing
      store to dictionary by introducing new nonextensible elements kind.
      These new nonextensible elements kind are handled similar to frozen,
      sealed element kinds. This change not only fixes the problem but also
      optimize the performance of nonextensible objects.
      
      Change-Id: Iffc7f14eb48223c11abf3c577f305d2d072eb65b
      Bug: chromium:992914, v8:6831
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760976
      Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63432}
      1f4bec27
  13. 20 Aug, 2019 1 commit
  14. 02 Jul, 2019 1 commit
  15. 01 Jul, 2019 1 commit
  16. 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
  17. 11 Jun, 2019 1 commit
  18. 24 May, 2019 1 commit
  19. 23 May, 2019 1 commit
  20. 22 May, 2019 1 commit
  21. 20 May, 2019 1 commit
  22. 17 May, 2019 2 commits
  23. 10 May, 2019 1 commit
  24. 07 May, 2019 1 commit
  25. 09 Apr, 2019 1 commit
  26. 12 Mar, 2019 1 commit
  27. 26 Dec, 2018 1 commit
  28. 17 Dec, 2018 1 commit
  29. 07 Dec, 2018 1 commit
  30. 25 Nov, 2018 1 commit
  31. 24 Nov, 2018 1 commit
  32. 13 Nov, 2018 1 commit
  33. 07 Nov, 2018 1 commit
  34. 17 Sep, 2018 1 commit
  35. 14 Sep, 2018 2 commits
    • Marja Hölttä's avatar
      Revert "[in-place weak refs] Fix MaybeObject function names" · 3a79fe23
      Marja Hölttä authored
      This reverts commit ad72d195.
      
      Reason for revert: Build failures on *san
      
      Original change's description:
      > [in-place weak refs] Fix MaybeObject function names
      > 
      > E.g., "ToWeakHeapObject" was misleading, since it didn't convert to a weak heap
      > object, instead returned a weakly pointed heap object. Change the function names
      > (in this case, to "GetHeapObjectIfWeak") to reflect this.
      > 
      > Also make casts explicit, if a MaybeObject is an Object, we can call cast<Object>().
      > 
      > BUG=v8:7308
      > 
      > Change-Id: I4ef078572b4f4415afe7e2e706d3bd684e16e47d
      > Reviewed-on: https://chromium-review.googlesource.com/1219025
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Commit-Queue: Marja Hölttä <marja@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55906}
      
      TBR=ulan@chromium.org,marja@chromium.org,yangguo@chromium.org,ahaas@chromium.org,tebbi@chromium.org,ishell@chromium.org
      
      Change-Id: I054b578518e3f6fd7dbcddf0b56cc018726c1e7a
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7308
      Reviewed-on: https://chromium-review.googlesource.com/1226874Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55918}
      3a79fe23
    • Marja Hölttä's avatar
      [in-place weak refs] Fix MaybeObject function names · ad72d195
      Marja Hölttä authored
      E.g., "ToWeakHeapObject" was misleading, since it didn't convert to a weak heap
      object, instead returned a weakly pointed heap object. Change the function names
      (in this case, to "GetHeapObjectIfWeak") to reflect this.
      
      Also make casts explicit, if a MaybeObject is an Object, we can call cast<Object>().
      
      BUG=v8:7308
      
      Change-Id: I4ef078572b4f4415afe7e2e706d3bd684e16e47d
      Reviewed-on: https://chromium-review.googlesource.com/1219025Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55906}
      ad72d195
  36. 12 Sep, 2018 1 commit
  37. 24 Aug, 2018 1 commit
  38. 23 Aug, 2018 1 commit