Skip to content

V
V8
Switch branch/tag
  1. 18 Jun, 2021 1 commit
  3. 17 Jun, 2021 1 commit
  5. 14 Jun, 2021 1 commit
  7. 07 Jun, 2021 1 commit
  9. 18 May, 2021 1 commit
  11. 26 Apr, 2021 1 commit
  13. 21 Apr, 2021 1 commit
  15. 19 Apr, 2021 1 commit
  17. 16 Apr, 2021 1 commit
  19. 12 Apr, 2021 1 commit
  21. 31 Mar, 2021 1 commit
  23. 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
  25. 03 Mar, 2021 1 commit
  27. 02 Mar, 2021 1 commit
  29. 19 Feb, 2021 2 commits
    • Frank Emrich's avatar
      [dict-proto] C++ implementation of SwissNameDictionary, pt. 3 · a2c31f74
      Frank Emrich authored 
      This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/2688058

This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.

This CL adds the initialization code, factory functions and a
canonical SwissNameDictionary plus all helpers required for that.

Bug: v8:11388
Change-Id: I9cf66a3fa755288f7730f55abfb6e6cea82f6b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2703653
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72857}
      a2c31f74
    • 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
  31. 17 Feb, 2021 3 commits
  33. 04 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      [literals] Add a dedicated regexp boilerplate type · e79b841b
      Jakob Gruber authored 
      ... and mark it as never-serialized wrt turbofan serialization.

Until this CL, the JSRegExp type was used as both for plain
user-visible regexp objects, and for internal regexp boilerplate
descriptions. Boilerplates are special: they are never exposed to the
user, they are only referenced from the feedback vector, they are
immutable.

To clarify this distinction, this CL introduces a dedicated struct
type RegExpBoilerplateDescription to hold the regexp boilerplate
description.

This makes Turbofan serialization simpler: boilerplates can be
accessed through direct reads since they are immutable. TF has no
special requirements on JSRegExp objects (it never reads into these
objects) and thus serializing only the references as a JSObjectRef is
fine.

Bug: v8:7790
Change-Id: I33b337fcfcf861a02bc6be6d0c6311d07cf05718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656257Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@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@{#72522}
      e79b841b
  35. 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
  37. 05 Jan, 2021 1 commit
  39. 25 Nov, 2020 1 commit
  41. 23 Nov, 2020 1 commit
  43. 20 Nov, 2020 1 commit
  45. 17 Nov, 2020 1 commit
  47. 16 Nov, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add string access lock to GetChars · df842562
      Leszek Swirski authored 
      Add a requirement to String::GetChars that we either have a string
access lock, or a string access lock is not needed. This prevents us
from reading strings during internalization that may be in the middle
of being made external.

To avoid taking the lock too often when known to be unnecessary (e.g.
for strings that were only just created), there's now a static
SharedStringAccessGuardIfNeeded::NotNeeded(). This is hopefully ugly
enough that it's used sparingly.

One fix required for this is to enter the Isolate when tearing down
IsolateData in inspector tests -- this is so that the V8Inspector
instance being torn down will see the current Isolate and be able to
verify its thread id against the current thread.

Bug: chromium:1011762, chromium:1148680
Change-Id: Ic5d29c1b066ebae5a351c7b4bb116b9b1bf61889
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536465
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71197}
      df842562
  49. 11 Nov, 2020 1 commit
  51. 09 Nov, 2020 1 commit
  53. 03 Nov, 2020 1 commit
  55. 26 Oct, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Support block coverage in off-thread finalization · 08b68464
      Leszek Swirski authored 
      Move CoverageInfo installation to the main-thread part of finalization.
Since this is debug-only, it won't affect non-debug compiles.

This allows us to use off-thread finalization when block coverage is
enabled, removing the last non-flag reason for disabling off-thread
finalization. This means we can remove the per-task "finalize
off-thread" flag on BackgroundCompileTask, and make off-thread
finalization always on when the flag is on.

Bug: chromium:1011762
Change-Id: Ib733d501c4043b493ded9a1951cceb5cfc524eb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2497177
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70758}
      08b68464
  57. 16 Oct, 2020 1 commit
    • Pierre Langlois's avatar
      [heap] Make maximum regular code object size a runtime value. · f4376ec8
      Pierre Langlois authored 
      Executable V8 pages include 3 reserved OS pages: one for the writable
header and two as guards. On systems with 64k OS pages, the amount of
allocatable space left for objects can then be quite smaller than the
page size, only 64k for each 256k page.

This means regular code objects cannot be larger than 64k, while the
maximum regular object size is fixed to 128k, half of the page size. As
a result code object never reach this limit and we can end up filling
regular pages with few large code objects.

To fix this, we change the maximum code object size to be runtime value,
set to half of the allocatable space per page. On systems with 64k OS
pages, the limit will be 32k.

Alternatively, we could increase the V8 page size to 512k on Arm64 linux
so we wouldn't waste code space. However, systems with 4k OS pages are
more common, and those with 64k pages tend to have more memory available
so we should be able to live with it.

Bug: v8:10808
Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#70569}
      f4376ec8
  59. 15 Oct, 2020 1 commit
  61. 08 Oct, 2020 1 commit
  63. 05 Oct, 2020 1 commit
  65. 08 Sep, 2020 1 commit
  67. 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
  69. 06 Aug, 2020 1 commit
  71. 17 Jun, 2020 1 commit
    • Dan Elphick's avatar
      [heap] Use BasicMemoryChunk::FromHeapObject more · 6f267e8a
      Dan Elphick authored 
      Since ReadOnlySpace pages will soon not be MemoryChunks, change most
uses of MemoryChunk::FromHeapObject and FromAddress to use the
BasicMemoryChunk variants and which use the new MemoryChunk::cast
function that takes a BasicMemoryChunk and DCHECKs !InReadOnlySpace().

To enable this, it also moves into BasicMemoryChunk several MemoryChunk
functions that just require a BasicMemoryChunk.

Bug: v8:10454
Change-Id: I80875b2c2446937ac2c2bc9287d36e71cc050c38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2243216
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68390}
      6f267e8a
  73. 05 May, 2020 1 commit