Skip to content

V
V8
Switch branch/tag
  1. 16 Mar, 2022 1 commit
  3. 10 Feb, 2022 1 commit
  5. 04 Feb, 2022 1 commit
  7. 25 Jan, 2022 1 commit
  9. 24 Nov, 2021 1 commit
    • Samuel Groß's avatar
      ArrayBuffer refactoring in preparation for CagedPointers · 6e68daf7
      Samuel Groß authored 
      The main changes of this CL are:

It should no longer be assumed that an empty ArrayBuffer has a nullptr
backing store. This is in preparation for the move to caged pointers,
which cannot represent nullptr, and will instead likely provide a
EmptyBackingStore constant pointing inside the virtual memory cage. For
that reason, a new JSArrayBuffer::IsEmpty() helper is introduced, which
should be used instead of checking against nullptr.

CodeStubAssembler::GetTypedArrayBuffer now checks for on-heap
TypedArrays instead of comparing the backing store pointer to nullptr.
This is consistent with the implementation in JSTypedArray::GetBuffer.

v8::ArrayBufferView::CopyContents now uses JSTypedArray::DataPtr instead
of relying on nullptr backing stores to handle on-heap TypedArrays.

The serializer and deserializer now check for IsEmpty() and use the
kEmptyBackingStoreRefSentinel value to serialize empty backing stores.

Empty ArrayBuffers allocated for on-heap TypedArrays now have a
byte_length of zero. This allows removing the allocation_length() (and
allocation_buffer()) methods, which were only (incorrectly, as they
don't account for GSABs) used for memory measurements.

Bug: chromium:1218005
Change-Id: Ib889ccf855f68525f7a614f3963e46ea56865fa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297709Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78069}
      6e68daf7
  11. 23 Nov, 2021 2 commits
  13. 22 Nov, 2021 1 commit
  15. 21 Jul, 2021 1 commit
  17. 10 May, 2021 1 commit
  19. 11 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      Reland "[compiler] Don't serialize JSTypedArray fields" · 28105df3
      Jakob Gruber authored 
      This is a reland of da785659

The reland overrides ShouldHaveBeenSerialized for typed array
refs to avoid disabling related optimizations when direct heap
access is enabled.

Original change's description:
> [compiler] Don't serialize JSTypedArray fields
>
> This CL removes serialization of JSTypedArray fields when direct heap
> reads are enabled. Invariants we rely on:
>
> - Of the underlying interesting fields,
>   - base_pointer and external_pointer are set either during
>     initialization, or in a one-time on-to-off-heap transition in
>     GetBuffer.
>   - length and buffer are immutable after initialization.
> - is_on_heap and DataPtr derive from base_pointer and
>   external_pointer s.t. is_on_heap == (base_pointer != 0) and
>   DataPtr == external_pointer in the off-heap case.
>
> In this CL we add one new invariant:
>
> - For all base_pointer and external_pointer mutations after
>   initialization, base_pointer is guaranteed to be release-stored
>   after external_pointer has been written.
>
> With these invariants, concurrent access to off-heap typed arrays is
> trivial as long as is_on_heap (= base_pointer) is read before other
> relevant fields.
>
> Note that JSTypedArray remains a kSerializedHeapObject due to the
> serialized superclass JSObject.
>
> Drive-by: Remove unused Torque operators and empty TODOs.
>
> Bug: v8:7790
> Change-Id: I3c4327318f94e4e6083d4e87476069aad2649386
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679689
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72572}

Bug: v8:7790
Change-Id: I87b37de983e8cf89ca53b5efae7ab195781f3df5
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689182Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72652}
      28105df3
  21. 09 Feb, 2021 2 commits
    • Jakob Gruber's avatar
      Revert "[compiler] Don't serialize JSTypedArray fields" · 5e568739
      Jakob Gruber authored 
      This reverts commit da785659.

Reason for revert: Investigating regressions https://chromeperf.appspot.com/group_report?rev=72572

Original change's description:
> [compiler] Don't serialize JSTypedArray fields
>
> This CL removes serialization of JSTypedArray fields when direct heap
> reads are enabled. Invariants we rely on:
>
> - Of the underlying interesting fields,
>   - base_pointer and external_pointer are set either during
>     initialization, or in a one-time on-to-off-heap transition in
>     GetBuffer.
>   - length and buffer are immutable after initialization.
> - is_on_heap and DataPtr derive from base_pointer and
>   external_pointer s.t. is_on_heap == (base_pointer != 0) and
>   DataPtr == external_pointer in the off-heap case.
>
> In this CL we add one new invariant:
>
> - For all base_pointer and external_pointer mutations after
>   initialization, base_pointer is guaranteed to be release-stored
>   after external_pointer has been written.
>
> With these invariants, concurrent access to off-heap typed arrays is
> trivial as long as is_on_heap (= base_pointer) is read before other
> relevant fields.
>
> Note that JSTypedArray remains a kSerializedHeapObject due to the
> serialized superclass JSObject.
>
> Drive-by: Remove unused Torque operators and empty TODOs.
>
> Bug: v8:7790
> Change-Id: I3c4327318f94e4e6083d4e87476069aad2649386
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679689
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72572}

TBR=neis@chromium.org,jgruber@chromium.org

Change-Id: I5a7e6bacb7b7a3e3510c778837679e6822f26339
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7790
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681948Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72583}
      5e568739
    • Jakob Gruber's avatar
      [compiler] Don't serialize JSTypedArray fields · da785659
      Jakob Gruber authored 
      This CL removes serialization of JSTypedArray fields when direct heap
reads are enabled. Invariants we rely on:

- Of the underlying interesting fields,
  - base_pointer and external_pointer are set either during
    initialization, or in a one-time on-to-off-heap transition in
    GetBuffer.
  - length and buffer are immutable after initialization.
- is_on_heap and DataPtr derive from base_pointer and
  external_pointer s.t. is_on_heap == (base_pointer != 0) and
  DataPtr == external_pointer in the off-heap case.

In this CL we add one new invariant:

- For all base_pointer and external_pointer mutations after
  initialization, base_pointer is guaranteed to be release-stored
  after external_pointer has been written.

With these invariants, concurrent access to off-heap typed arrays is
trivial as long as is_on_heap (= base_pointer) is read before other
relevant fields.

Note that JSTypedArray remains a kSerializedHeapObject due to the
serialized superclass JSObject.

Drive-by: Remove unused Torque operators and empty TODOs.

Bug: v8:7790
Change-Id: I3c4327318f94e4e6083d4e87476069aad2649386
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679689
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72572}
      da785659
  23. 19 Jan, 2021 1 commit
  25. 29 Sep, 2020 1 commit
  27. 12 Aug, 2020 1 commit
  29. 11 May, 2020 1 commit
    • Seth Brenith's avatar
      [torque][cleanup] Simplify some Torque-defined classes · e7693985
      Seth Brenith authored 
      This CL is pretty mechanical; I just iterated through some Torque
classes making the following changes:

- Use @generateCppClass if it seems easy to
- Use @generatePrint if the existing printer doesn't do anything special
- Fix up any imprecise field types

It also includes two minor changes to implementation-visitor:

- Add a new -inl.h file with the things needed for
  torque-generated/class-definitions-tq.cc so we don't need to keep
  changing the compiler when we add @generateCppClass.
- Avoid emitting incorrect accessors for ExternalPointers. This isn't
  strictly necessary for correctness, as the accessors defined in C++
  already hide the ones inherited from generated code, but it makes me
  feel safer.

Change-Id: I4d5a8ba6f86ebff57a0d147619212a3993b087c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2185824Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#67719}
      e7693985
  31. 08 May, 2020 1 commit
  33. 04 May, 2020 1 commit
  35. 01 May, 2020 1 commit
  37. 28 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Complete Torque definition of JSArrayBuffer · da900ffe
      Seth Brenith authored 
      Previously, our Torque definition of JSArrayBuffer included only the
first two fields. This allowed access to those two fields, but was
somewhat confusing and obviously didn't let Torque code access the
other fields. This change:

- Completes the JSArrayBuffer layout definition;
- Moves the associated bitfield struct definition to Torque;
- Moves a couple of JSArrayBuffer macros to Torque;
- Adds a reducer case so that the code generated using these new macros
  is not worse than what was generated previously.

Change-Id: Ib19c3ba789a33801fa9d0d064cd21d62a1e03e30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2053769
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66503}
      da900ffe
  39. 11 Nov, 2019 1 commit