1. 13 May, 2022 1 commit
  2. 10 Feb, 2022 1 commit
  3. 28 Jan, 2022 1 commit
  4. 27 Jan, 2022 4 commits
  5. 24 Jan, 2022 1 commit
    • Joyee Cheung's avatar
      Reland "[class] implement reparsing of class instance member initializers" · 0e07eb53
      Joyee Cheung authored
      This is a reland of 91f08378
      
      When the class scope does not need a context, the deserialized
      outer scope of the initializer scope would not be the class scope,
      and we should not and do not need to use it to fix up the allocation
      information of the context-allocated variables. The original patch
      did not consider this case and resulted in a regression when we
      tried to reparse the initializer function to look for destructuring
      assignment errors. This fixes the regression by not deserializing
      the class scope that's going to be reparsed, and using the positions
      of the scopes to tell whether the scope info matches the reparsed
      scope and can be used to fix up the allocation info.
      
      Original change's description:
      > [class] implement reparsing of class instance member initializers
      >
      > Previously, since the source code for the synthetic class instance
      > member initializer function was recorded as the span from the first
      > initializer to the last initializer, there was no way to reparse the
      > class and recompile the initializer function. It was working for
      > most use cases because the code for the initializer function was
      > generated eagarly and it was usually alive as long as the class was
      > alive, so the initializer wouldn't normally be lazily parsed. This
      > didn't work, however, when the class was snapshotted with
      > v8::SnapshotCreator::FunctionCodeHandling::kClear,
      > becuase then we needed to recompile the initializer when the class
      > was instantiated. This patch implements the reparsing so that
      > these classes can work with FunctionCodeHandling::kClear.
      >
      > This patch refactors ParserBase::ParseClassLiteral() so that we can
      > reuse it for both parsing the class body normally and reparsing it
      > to collect initializers. When reparsing the synthetic initializer
      > function, we rewind the scanner to the beginning of the class, and
      > parse the class body to collect the initializers. During the
      > reparsing, field initializers are parsed with the full parser while
      > methods of the class are pre-parsed.
      >
      > A few notable changes:
      >
      > - Extended the source range of the initializer function to cover the
      >   entire class so that we can rewind the scanner to parse the class
      >   body to collect initializers (previously, it starts from the first
      >   field initializer and ends at the last initializer). This resulted
      >   some expectation changes in the debugger tests, though the
      >   initializers remain debuggable.
      > - A temporary ClassScope is created during reparsing. After the class
      >   is reparsed, we use the information from the ScopeInfo to update
      >   the allocated indices of the variables in the ClassScope.
      >
      > Bug: v8:10704
      > Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Cr-Commit-Position: refs/heads/main@{#78299}
      
      Bug: chromium:1278086, chromium:1278085, v8:10704
      Change-Id: Iea4f1f6dc398846cbe322adc16f6fffd6d2dfdf3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325912Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#78745}
      0e07eb53
  6. 17 Jan, 2022 1 commit
    • Victor Gomes's avatar
      Reland "[runtime] Adds LocalNameIterator" · 4ebc9b7b
      Victor Gomes authored
      This is a reland of f605d778
      
      Adds a GC safe (using handles) and unsafe versions of the iterator.
      
      V8HeapExplorer needs an unsafe one, since it does not allow the
      creation of handles.
      
      Original change's description:
      > [runtime] Adds LocalNameIterator
      >
      > ScopeInfo will contain either inlined (array) local names or
      > a hash table (names => index) containing the local names.
      >
      > We abstract iteration with LocalNameIterator and remove
      > ContextLocalName since accessing a local name by index in
      > the hash table would be expensive.
      >
      > This CL only implements the iterator for the array.
      >
      > Bug: v8:12315
      > Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78623}
      
      Bug: v8:12315
      Change-Id: I6288a08b9c342cd3a9cabcb621c40bb44c08c9c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3394706Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78653}
      4ebc9b7b
  7. 14 Jan, 2022 3 commits
    • Leszek Swirski's avatar
      Revert "[runtime] Adds LocalNameIterator" · 1e42a27f
      Leszek Swirski authored
      This reverts commit f605d778.
      
      Reason for revert: Segfaults: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/36908/overview
      
      Original change's description:
      > [runtime] Adds LocalNameIterator
      >
      > ScopeInfo will contain either inlined (array) local names or
      > a hash table (names => index) containing the local names.
      >
      > We abstract iteration with LocalNameIterator and remove
      > ContextLocalName since accessing a local name by index in
      > the hash table would be expensive.
      >
      > This CL only implements the iterator for the array.
      >
      > Bug: v8:12315
      > Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78623}
      
      Bug: v8:12315
      Change-Id: Ibabe231f4357a3dd02d24b89847d579b83867a1a
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386385
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78625}
      1e42a27f
    • Victor Gomes's avatar
      [runtime] Adds LocalNameIterator · f605d778
      Victor Gomes authored
      ScopeInfo will contain either inlined (array) local names or
      a hash table (names => index) containing the local names.
      
      We abstract iteration with LocalNameIterator and remove
      ContextLocalName since accessing a local name by index in
      the hash table would be expensive.
      
      This CL only implements the iterator for the array.
      
      Bug: v8:12315
      Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78623}
      f605d778
    • Victor Gomes's avatar
      [runtime] Update SavedClassVariable in ScopeInfo · 2fdc823a
      Victor Gomes authored
      ScopeInfo will contain either inlined (array) local names or
      a hash table (names => index) containing the local names.
      
      If we have the local names inlined, we should save the class
      variable context slot index.
      
      If we have a hash table instead, we should save the class
      variable offset in the internal hash table storage.
      
      Bug: v8:12315
      Change-Id: Ifd9ae4f285d11fc034e8560c8558038b38a474fb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386599Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78621}
      2fdc823a
  8. 16 Nov, 2021 1 commit
  9. 09 Nov, 2021 1 commit
  10. 26 Oct, 2021 1 commit
  11. 12 Oct, 2021 1 commit
  12. 08 Oct, 2021 1 commit
  13. 07 Jul, 2021 1 commit
  14. 01 Jul, 2021 1 commit
  15. 21 May, 2021 1 commit
  16. 19 May, 2021 1 commit
  17. 26 Apr, 2021 1 commit
  18. 06 Apr, 2021 1 commit
    • Shu-yu Guo's avatar
      Reland^2 "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 627b6b2f
      Shu-yu Guo authored
      This is a reland of e28dadc2
      
      The original failure was due to a stale Win32 bot. The reland failure
      was due to idempotent task deduplication returning the exact same
      failure. See crbug/1196064
      
      Original change's description:
      > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      >
      > Currently, IsolateRoot is both the address of the Isolate root and the
      > base address of the pointer compression reservation. This CL teases the
      > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      >
      > - In addition to V8_COMPRESS_POINTERS, add a
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      >
      > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      >   aliases to GetPtrComprCageBase.
      >
      > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      >
      > Bug: v8:11460
      > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Auto-Submit: Shu-yu Guo <syg@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73790}
      
      Bug: v8:11460
      No-Try: true
      Tbr: ishell@chromium.org
      Tbr: rmcilroy@chromium.org
      Change-Id: Id69311cf3267ebe1297fff159de0be48b15b65a3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806546Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73795}
      627b6b2f
  19. 05 Apr, 2021 4 commits
    • Shu-yu Guo's avatar
      Revert "Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase"" · 562c4251
      Shu-yu Guo authored
      This reverts commit 15c78b45.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32277/overview
      
      Original change's description:
      > Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase"
      >
      > This is a reland of e28dadc2
      >
      > Relanding to see if Win32 rel failures from
      > https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview
      > were infra flakes. Could not repro on try bots.
      >
      > Original change's description:
      > > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      > >
      > > Currently, IsolateRoot is both the address of the Isolate root and the
      > > base address of the pointer compression reservation. This CL teases the
      > > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      > >
      > > - In addition to V8_COMPRESS_POINTERS, add a
      > >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      > >
      > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      > >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      > >   aliases to GetPtrComprCageBase.
      > >
      > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      > >
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      >
      > No-Try: true
      > Bug: v8:11460
      > Tbr: ishell@chromium.org
      > Tbr: rmcilroy@chromium.org
      > Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169
      > Reviewed-by: Shu-yu Guo <syg@chromium.org>
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73792}
      
      Bug: v8:11460
      Change-Id: Ifee92d622c43a91c15f45ef94ff739237bd2024b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806545
      Auto-Submit: Shu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73793}
      562c4251
    • Shu-yu Guo's avatar
      Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 15c78b45
      Shu-yu Guo authored
      This is a reland of e28dadc2
      
      Relanding to see if Win32 rel failures from
      https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview
      were infra flakes. Could not repro on try bots.
      
      Original change's description:
      > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      >
      > Currently, IsolateRoot is both the address of the Isolate root and the
      > base address of the pointer compression reservation. This CL teases the
      > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      >
      > - In addition to V8_COMPRESS_POINTERS, add a
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      >
      > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      >   aliases to GetPtrComprCageBase.
      >
      > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      >
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      
      No-Try: true
      Bug: v8:11460
      Tbr: ishell@chromium.org
      Tbr: rmcilroy@chromium.org
      Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73792}
      15c78b45
    • Francis McCabe's avatar
      Revert "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 07a9ff4d
      Francis McCabe authored
      This reverts commit e28dadc2.
      
      Reason for revert: failed test262 tests;; see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/steps?succeeded=true&debug=false
      
      Original change's description:
      > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      >
      > Currently, IsolateRoot is both the address of the Isolate root and the
      > base address of the pointer compression reservation. This CL teases the
      > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      >
      > - In addition to V8_COMPRESS_POINTERS, add a
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      >
      > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      >   aliases to GetPtrComprCageBase.
      >
      > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      >
      > Bug: v8:11460
      > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Auto-Submit: Shu-yu Guo <syg@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73790}
      
      Bug: v8:11460
      Change-Id: I19d0e28194fcdb28e89f129a7694ca3fe29fa17a
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806168
      Auto-Submit: Francis McCabe <fgm@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#73791}
      07a9ff4d
    • Shu-yu Guo's avatar
      [ptr-cage] Rename IsolateRoot to PtrComprCageBase · e28dadc2
      Shu-yu Guo authored
      Currently, IsolateRoot is both the address of the Isolate root and the
      base address of the pointer compression reservation. This CL teases the
      two uses apart by renaming IsolateRoot to PtrComprCageBase.
      
      - In addition to V8_COMPRESS_POINTERS, add a
        V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      
      - Rename GetIsolate* helpers to GetPtrComprCageBase. When
        V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
        aliases to GetPtrComprCageBase.
      
      - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      
      Bug: v8:11460
      Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Auto-Submit: Shu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73790}
      e28dadc2
  20. 15 Mar, 2021 1 commit
  21. 08 Mar, 2021 1 commit
    • Seth Brenith's avatar
      Remove 'length' field from ScopeInfo · 90a66422
      Seth Brenith authored
      This change relands the last part of https://crrev.com/c/2601880 .
      
      ScopeInfo has a vestigial 'length' field from when it used to be a
      FixedArray. This change removes that field, which saves some memory.
      
      More specifically:
      
      - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
        supplied the 'length' field.
      - Change FactoryBase::NewScopeInfo to allocate the updated object shape.
        It maintains the existing behavior of filling the newly-allocated
        object with undefined, even though that's not a valid ScopeInfo and
        further initialization is required.
      - Change a few length computations to use HeapObject::kHeaderSize rather
        than FixedArray::kHeaderSize.
      - Remove an unnecessary heap verifier function.
      
      Change-Id: I9b3980157568fdb0402fa31660949966b401fd31
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2733037Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#73278}
      90a66422
  22. 03 Mar, 2021 1 commit
    • Seth Brenith's avatar
      Privatize FixedArray-style accessors on ScopeInfo · 3a366c4d
      Seth Brenith authored
      This is a partial reland of https://crrev.com/c/2601880 .
      
      In preparation for ScopeInfo not being a FixedArrayBase, this change
      privatizes the FixedArray-style functions that provide access to
      ScopeInfo fields by index, and moves them from scope-info-inl.h to
      scope-info.cc. Those functions are still used pretty heavily during
      initialization (ScopeInfo::Create, etc.), but at least we can avoid
      presenting them to the rest of the world.
      
      This change also introduces a new length() function in ScopeInfo which
      hides the one inherited from FixedArrayBase and computes the ScopeInfo's
      length based on its flags, so that there are no remaining readers of the
      'length' field.
      
      Change-Id: I609754010723b679e5cf00f386020faaab84c17a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718275
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73151}
      3a366c4d
  23. 24 Feb, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Add a way to specify that a class field is optional · c2d419a3
      Seth Brenith authored
      Currently, some ScopeInfo fields are defined as indexed fields with a
      length of either one or zero, because the field might be present or it
      might not. Based on comments in https://crrev.com/c/v8/v8/+/2601880 ,
      this strategy is not sustainable and we need a better way to represent
      optional fields so that we don't have to pass zero when accessing their
      only element. This change is a proposal to fix that problem.
      
      Syntax:
      
      I'm proposing using a question mark because TypeScript does, and Torque
      syntax looks somewhat like TypeScript. I don't feel strongly about this
      though, and I'm open to other suggestions.
        field_name?[condition_expression]: FieldType;
      
      Internal Torque compiler representation:
      
      Internally, I've updated the Torque compiler to still treat these fields
      as indexed, but with an extra flag saying they're optional. When getting
      a LocationReference for a field access expression on an optional field,
      Torque produces a Slice like it would for any other indexed field and
      subsequently calls AtIndex(0) to get a Reference.
      
      AtIndex can crash the process if the index is out of bounds (which is
      good), so some other parts of the Torque compiler need minor adjustments
      so that it doesn't take references to optional fields unless it actually
      needs them.
      
      Initialization:
      
      This proposal doesn't include any changes to initialization logic, so an
      optional field can still be initialized using '...' and an iterator.
      Perhaps we could introduce an Optional<T> struct for prettier
      initialization in a future change.
      
      Bug: v8:7793
      Change-Id: I37649495f4c259e685261f53e4cf2859da66a31f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706306
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73018}
      c2d419a3
  24. 19 Feb, 2021 1 commit
    • Seth Brenith's avatar
      Revert "Remove 'length' field from ScopeInfo" · 6c922e39
      Seth Brenith authored
      This reverts commit f731e13f.
      
      Reason for revert: perf regressions, chromium:1179757
      
      Original change's description:
      > Remove 'length' field from ScopeInfo
      >
      > ScopeInfo has a vestigial 'length' field from when it used to be a
      > FixedArray. This change removes that field, which saves some memory.
      >
      > More specifically:
      >
      > - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
      >   supplied the 'length' field.
      > - Privatize the FixedArray-style functions that provide access to
      >   ScopeInfo fields by index, and move them from scope-info-inl.h to
      >   scope-info.cc. Those functions are still used pretty heavily during
      >   initialization (ScopeInfo::Create, etc.), but at least we can avoid
      >   presenting them to the rest of the world.
      > - Change FactoryBase::NewScopeInfo to allocate the updated object shape.
      >   It maintains the existing behavior of filling the newly-allocated
      >   object with undefined, even though that's not a valid ScopeInfo and
      >   further initialization is required.
      > - Move part of AccessorAssembler::ScriptContextTableLookup into a new
      >   Torque macro, because it used to rely on casting ScopeInfo to
      >   FixedArrayBase.
      > - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
      >   arrays. I think it makes more sense to list them under "(system)" in
      >   the dev tools, like most other V8 internal types.
      >
      > Bug: v8:8952
      > Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72830}
      
      Bug: v8:8952
      Change-Id: I00a69da79e5ac6aaae4436a41ce773ae014cc775
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706086
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Auto-Submit: Seth Brenith <seth.brenith@microsoft.com>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72855}
      6c922e39
  25. 17 Feb, 2021 1 commit
    • Seth Brenith's avatar
      Remove 'length' field from ScopeInfo · f731e13f
      Seth Brenith authored
      ScopeInfo has a vestigial 'length' field from when it used to be a
      FixedArray. This change removes that field, which saves some memory.
      
      More specifically:
      
      - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
        supplied the 'length' field.
      - Privatize the FixedArray-style functions that provide access to
        ScopeInfo fields by index, and move them from scope-info-inl.h to
        scope-info.cc. Those functions are still used pretty heavily during
        initialization (ScopeInfo::Create, etc.), but at least we can avoid
        presenting them to the rest of the world.
      - Change FactoryBase::NewScopeInfo to allocate the updated object shape.
        It maintains the existing behavior of filling the newly-allocated
        object with undefined, even though that's not a valid ScopeInfo and
        further initialization is required.
      - Move part of AccessorAssembler::ScriptContextTableLookup into a new
        Torque macro, because it used to rely on casting ScopeInfo to
        FixedArrayBase.
      - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
        arrays. I think it makes more sense to list them under "(system)" in
        the dev tools, like most other V8 internal types.
      
      Bug: v8:8952
      Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72830}
      f731e13f
  26. 11 Feb, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Generate accessors for struct-typed class fields · 6160a767
      Seth Brenith authored
      Torque generates runtime accessor member functions for most class fields
      that are defined in .tq files, but fields with struct types are
      currently omitted. This change adds those accessors. As an example, if a
      .tq file defines the following:
      
        struct InternalClassStructElement {
          a: Smi;
          b: Smi;
        }
      
        class InternalClassWithStructElements extends HeapObject {
          const count: Smi;
          entries[count]: InternalClassStructElement;
        }
      
      Then the following accessors are generated to get and set each struct
      field within the 'entries' field:
      
        inline int entries_a(int i) const;
        inline void set_entries_a(int i, int value);
      
        inline int entries_b(int i) const;
        inline void set_entries_b(int i, int value);
      
      Bug: v8:7793
      Change-Id: Ia40b5918e9d09f53ad8e78bc33f8629b8d6a79fe
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676926Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72662}
      6160a767
  27. 20 Jan, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Begin porting ScopeInfo to Torque · ecaac329
      Seth Brenith authored
      This change adds Torque field definitions for ScopeInfo and begins to
      use the Torque-generated accessors in some places. It does not change
      the in-memory layout of ScopeInfo.
      
      Torque compiler changes:
      
      - Fix an issue where the parser created constexpr types for classes
        based on the class name rather than the `generates` clause. This meant
        that generated accessors referred to the imaginary type HashTable
        rather than the real C++ type FixedArray.
      - Don't pass Isolate* through the generated runtime functions that
        implement Torque macros. Maybe we'll need it eventually, but we don't
        right now and it complicates a lot of things.
      - Don't emit `kSomeFieldOffset` if some_field has an unknown offset.
        Instead, emit a member function `SomeFieldOffset()` which fetches the
        slice for some_field and returns its offset.
      - Emit an `AllocatedSize()` member function for classes which have
        complex length expressions. It fetches the slice for the last field
        and performs the multiply&add to compute the total object size.
      - Emit field accessors for fields with complex length expressions, using
        the new offset functions.
      - Fix a few minor bugs where Torque can write uncompilable code.
      
      With this change, most code still treats ScopeInfo like a FixedArray, so
      I would like to follow up with some additional changes:
      
      1. Generate a GC visitor for ScopeInfo and use it
      2. Generate accessors for struct-typed fields (indexed or otherwise),
         and use them
      3. Get rid of the FixedArray-style get and set accessors; use
         TaggedField::load and similar instead
      4. Inherit from HeapObject rather than FixedArrayBase to remove the
         unnecessary `length` field
      
      After that, there will only be one ugly part left: initialization. I
      think it's possible to generate a factory function that takes a bunch of
      iterator parameters and returns a fully-formed, verifiably correct
      ScopeInfo instance, but doing so is more complicated than the four
      mostly-mechanical changes listed above.
      
      Bug: v8:7793
      Change-Id: I55fcfe9189e4d1613c68d49e378da5dc02597b36
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357758Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72187}
      ecaac329
  28. 30 Nov, 2020 1 commit
    • Seth Brenith's avatar
      Require the first three fields of ScopeInfo to be present · 2bbf3333
      Seth Brenith authored
      ScopeInfo objects generally start with three fields: flags, parameter
      count, and local variable count. But a single read-only ScopeInfo
      instance has none of those fields. This is the empty ScopeInfo, which is
      used for contexts that don't correspond to any scope (the native context
      and contexts for builtin functions). Since there is only ever a single
      instance of the empty ScopeInfo, the memory savings of omitting these
      fields is trivial, and we can simplify logic somewhat by including them.
      Rather than checking for length to be zero, this change introduces a new
      flag indicating that a ScopeInfo instance is the empty one.
      
      On its own, this change doesn't provide a whole lot of value. However,
      it sets us up for two further improvements, which are consistent with
      the goals outlined in [1]:
      
      1. We should fully describe ScopeInfo fields in Torque. Getting rid of
      the requirement to check for emptiness would substantially simplify the
      indexed field expressions.
      
      2. ScopeInfo shouldn't inherit from FixedArray, and shouldn't begin with
      a `length` field when the length can be computed from the other fields.
      This would save a small amount of heap memory and avoid any possibility
      of a mismatch between the two ways of computing the length.
      
      [1] https://docs.google.com/document/d/1tiGK7_lubxPHnInI2vscUwMHfadn8gIEa1apmI8HxR4/edit#heading=h.n63k76b3zfwa
      
      Bug: v8:8952
      Change-Id: I018127698a5d91fb2a91684bc3aec2e27ee27c41
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2561598Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71500}
      2bbf3333
  29. 20 Nov, 2020 1 commit
  30. 11 Nov, 2020 1 commit
  31. 10 Nov, 2020 1 commit
    • Daniel Clark's avatar
      Plumb import assertions through SourceTextModuleDescriptor's ModuleRequestMap · ea0ccc7e
      Daniel Clark authored
      This change plumbs import assertions from SourceTextModuleDescriptor's
      ModuleRequestMap into SourceTextModuleInfo via a new ModuleRequest
      type, where previously there had been only the specifier.
      
      SourceTextModuleDescriptor::module_map now deduplicates module requests
      using the specifier and the import assertions.  Continuing to use the
      specifier alone would cause a loss of information in the event that
      a module imports from the same specifier multiple times using different
      sets of assertions.  Failing to deduplicate at all would result in
      multiple requests for statements like `import {a,b,c} from "foo.js"`,
      which would be a potential performance issue.  See design doc at
      https://docs.google.com/document/d/1yuXgNHSbTAPubT1Mg0JXp5uTrfirkvO1g5cHHCe-LmY
      for more detail on this decision.
      
      v8::internal::ModuleRequest holds the assertions as an array of the form
      [key1, value1, position1, key2, value2, assertion2, ...].  However the
      parser still needs to use a map, since duplicate assertion keys need to
      be detected at parse time.  A follow-up  change will ensure that
      assertions are sorted using a proper lexicographic sort.
      
      Bug: v8:10958
      Change-Id: Iff13fb9a37d58fc1622cd3cce78925ad2b7a14bb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493060
      Commit-Queue: Dan Clark <daniec@microsoft.com>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71066}
      ea0ccc7e
  32. 14 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Change OffThreadIsolate to LocalIsolate · f1589bbe
      Leszek Swirski authored
      This patch introduces a new LocalIsolate and LocalFactory, which use
      LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
      us to remove those classes, as well as the related OffThreadSpace,
      OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
      OffThreadLogger becomes LocalLogger.
      
      LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
      us to additionally remove the concept of "Finish" and "Publish" that the
      OffThreadIsolate had, and allows us to internalize strings directly with
      the newly-concurrent string table (where the implementation can now move
      to FactoryBase).
      
      This patch also removes the off-thread support from the deserializer
      entirely, as well as removing the LocalIsolateWrapper which allowed
      run-time distinction between Isolate and OffThreadIsolate. LocalHeap
      doesn't support the reservation model used by the deserializer, and we
      will likely move the deserializer to use LocalIsolate unconditionally
      once we figure out the details of how to do this.
      
      Bug: chromium:1011762
      
      Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69397}
      f1589bbe