1. 16 Aug, 2021 1 commit
  2. 30 Jun, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Concurrent JSGlobalObjectRef::GetPropertyCell · 76b9d98f
      Jakob Gruber authored
      .. and make JSGlobalObjectRef bg-serialized.
      
      GetPropertyCell was implemented as:
      
       LookupIterator it(holder, isolate, name, LookupIterator::OWN);
       it.TryLookupCachedProperty();
       if (it.state() == LookupIterator::DATA) it.GetPropertyCell();
      
      Due to concurrency requirements, we essentially have to reimplement
      this entire path for use in a concurrent setting:
      
       - Reads in some cases have to use relaxed or acquire semantics.
       - The IsPendingAllocation predicate must be called on some objects
         before reading into them.
       - Repeated reads of the same field must be avoided due to the
         possibility of concurrent modifications.
      
      This CL introduces two new methods:
      
      ConcurrentLookupIterator::TryGetPropertyCell implements the outer
      lookup logic, including the repeated lookup for accessors / cached
      property names.
      
      GlobalDictionary::TryFindPropertyCellForConcurrentLookupIterator is a
      slightly modified HashTable::FindEntry which follows the above rules.
      
      Bug: v8:7790
      Change-Id: Ic9a52da766afdfedce8efcbda92876845a17eed9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2959616Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75467}
      76b9d98f
  3. 25 Jun, 2021 1 commit
  4. 23 Jun, 2021 1 commit
  5. 07 Jun, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Remove use of serialized JSObjectRef::elements · 8769666e
      Jakob Gruber authored
      .. and replace them by elements read directly from the heap object.
      
      With this change, consistency between `map` and `elements` is
      no longer guaranteed. Users were updated, when necessary, to deal
      with this, e.g. by being more careful not to read out of bounds,
      by inserting new `actual_elements == elements_constant` runtime
      checks, or through a new compilation dependency that verifies
      unchanged elements at finalization time.
      
      Drive-by: inline GetElementsKind into callsites.
      
      Bug: v8:7790
      Change-Id: Ifba78182e185ff0d4e954e3be52f0eb24328c853
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2909655Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74977}
      8769666e
  6. 16 Mar, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Concurrent JSObjectRef::GetOwnConstantElement · 21a23587
      Jakob Gruber authored
      This CL implements the above in a concurrent setting without relying
      on serialization (except existing serialization to read a consistent
      JSObject state, which should be addressed in future work).
      
      There are three main cases in which GetOwnConstantElement can succeed:
      
      - Frozen elements are always constant. The backing store is immutable
      after initialization and can be accessed through relaxed reads.
      - String wrapper elements are always constant. The JSPrimitiveWrapper
      is immutable after initialization, and internalized Strings are
      protected by a mutex (other string kinds are currently not handled).
      - Dictionary elements may be constant. Since this case is not
      particularly important for the optimization, we leave it unimplemented
      for now.
      
      Bug: v8:7790
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_no_cm_rel_ng
      Change-Id: If2fbced50218ebd3930da8157cd2ae5eb83a8e02
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2717308Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73442}
      21a23587
  7. 08 Mar, 2021 1 commit
  8. 22 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      Reland "[compiler] Direct heap reads for JSArrayRef" · 2e844377
      Jakob Gruber authored
      This is a reland of 76a2ab06
      
      Changes since the original CL:
      - Handle unserialized elements (optional result in getter).
      - Merge should_access_heap and --turbo-direct-heap-access paths.
      - Slightly update the serialized path in GetOwnCowElement.
      - Fix the cctest, add a regression test.
      
      Atomic JSObject::elements/JSArray::length setters are addressed
      in this CL: crrev.com/c/2704076.
      
      Original change's description:
      > [compiler] Direct heap reads for JSArrayRef
      >
      > There are two aspects to the non-JSObject parts of JSArrayRef:
      >
      > - JSArrayRef::length. Relevant only in two spots, 1. when reading
      > (immutable) array boilerplates and 2. for GetOwnCowElement.
      >
      > - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
      > store. Relies on the invariant that cow backing stores are immutable.
      >
      > This CL renames the length accessor to length_unsafe to make the
      > danger explicit at callsites.
      >
      > For GetOwnCowElement the refactor is slightly larger, since we now
      > need to read into the backing store while keeping full control of
      > object reads (e.g. JSArray::length and JSArray::elements_kind). We
      > make all reads explicit at the call site by requiring that elements,
      > elements kind, and length are passed in as arguments to
      > GetOwnCowElement. Inside GetOwnCowElement, consistency between these
      > is *not* guaranteed due to concurrency. At runtime, consistency *is*
      > guaranteed through the reference-equality check on the elements seen
      > during compilation. The actual elements read is implemented in
      > ConcurrentLookupIterator::GetOwnCowElement.
      >
      > Bug: v8:7790
      > Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72834}
      
      Bug: v8:7790
      Change-Id: I7577ad554992cafff81099a28c34f27db9bd8042
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710431
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72904}
      2e844377
  9. 19 Feb, 2021 1 commit
    • Georg Neis's avatar
      Revert "[compiler] Direct heap reads for JSArrayRef" · 3cfe4fe0
      Georg Neis authored
      This reverts commit 76a2ab06.
      
      Reason for revert: A few issues, e.g.
      https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8854931126653780144/+/u/Check__flakes_/ArrayWithCowElements
      
      Original change's description:
      > [compiler] Direct heap reads for JSArrayRef
      >
      > There are two aspects to the non-JSObject parts of JSArrayRef:
      >
      > - JSArrayRef::length. Relevant only in two spots, 1. when reading
      > (immutable) array boilerplates and 2. for GetOwnCowElement.
      >
      > - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
      > store. Relies on the invariant that cow backing stores are immutable.
      >
      > This CL renames the length accessor to length_unsafe to make the
      > danger explicit at callsites.
      >
      > For GetOwnCowElement the refactor is slightly larger, since we now
      > need to read into the backing store while keeping full control of
      > object reads (e.g. JSArray::length and JSArray::elements_kind). We
      > make all reads explicit at the call site by requiring that elements,
      > elements kind, and length are passed in as arguments to
      > GetOwnCowElement. Inside GetOwnCowElement, consistency between these
      > is *not* guaranteed due to concurrency. At runtime, consistency *is*
      > guaranteed through the reference-equality check on the elements seen
      > during compilation. The actual elements read is implemented in
      > ConcurrentLookupIterator::GetOwnCowElement.
      >
      > Bug: v8:7790
      > Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72834}
      
      Bug: v8:7790, chromium:1180012
      Change-Id: I50e72380c544b2b78e1e3dc87a8249281b710912
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704666
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72860}
      3cfe4fe0
  10. 18 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Direct heap reads for JSArrayRef · 76a2ab06
      Jakob Gruber authored
      There are two aspects to the non-JSObject parts of JSArrayRef:
      
      - JSArrayRef::length. Relevant only in two spots, 1. when reading
      (immutable) array boilerplates and 2. for GetOwnCowElement.
      
      - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
      store. Relies on the invariant that cow backing stores are immutable.
      
      This CL renames the length accessor to length_unsafe to make the
      danger explicit at callsites.
      
      For GetOwnCowElement the refactor is slightly larger, since we now
      need to read into the backing store while keeping full control of
      object reads (e.g. JSArray::length and JSArray::elements_kind). We
      make all reads explicit at the call site by requiring that elements,
      elements kind, and length are passed in as arguments to
      GetOwnCowElement. Inside GetOwnCowElement, consistency between these
      is *not* guaranteed due to concurrency. At runtime, consistency *is*
      guaranteed through the reference-equality check on the elements seen
      during compilation. The actual elements read is implemented in
      ConcurrentLookupIterator::GetOwnCowElement.
      
      Bug: v8:7790
      Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72834}
      76a2ab06
  11. 11 Feb, 2021 1 commit
  12. 04 Feb, 2021 1 commit
  13. 24 Sep, 2020 2 commits
  14. 22 Sep, 2020 1 commit
  15. 02 Sep, 2020 1 commit
  16. 10 Jan, 2020 1 commit
  17. 09 Jan, 2020 1 commit
  18. 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
  19. 20 Nov, 2019 1 commit
  20. 18 Oct, 2019 1 commit
  21. 16 Oct, 2019 1 commit
  22. 11 Oct, 2019 1 commit
  23. 09 Jul, 2019 1 commit
  24. 26 Jun, 2019 1 commit
    • Leszek Swirski's avatar
      [map] Update map in PrepareForDataProperty · 9c1363e5
      Leszek Swirski authored
      Deprecated maps might not be updated before being passed to
      PrepareForDataProperty. If the target map is a dictionary map,
      then adding the data property can fail.
      
      As a drive-by, remove the dead ForTransitionHandler code, which
      was another (potentially unsafe) caller of PrepareForDataProperty
      
      Bug: chromium:977012
      Change-Id: I894bbc9bca2001555474a3570eb03fe6b0f69ddd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674029
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62377}
      9c1363e5
  25. 24 May, 2019 1 commit
  26. 23 May, 2019 2 commits
  27. 22 May, 2019 1 commit
  28. 20 May, 2019 1 commit
  29. 27 Apr, 2019 1 commit
  30. 26 Dec, 2018 1 commit
  31. 17 Dec, 2018 1 commit
  32. 08 Dec, 2018 1 commit
  33. 13 Nov, 2018 1 commit
  34. 29 Oct, 2018 1 commit
  35. 11 Sep, 2018 2 commits
  36. 30 Jul, 2018 1 commit
  37. 23 Jul, 2018 1 commit