Skip to content

V
V8
Switch branch/tag
  1. 08 Jul, 2021 3 commits
  3. 24 Jun, 2021 3 commits
  5. 18 Jun, 2021 1 commit
  7. 17 Jun, 2021 1 commit
  9. 14 Jun, 2021 1 commit
  11. 07 Jun, 2021 1 commit
  13. 18 May, 2021 1 commit
  15. 26 Apr, 2021 1 commit
  17. 21 Apr, 2021 1 commit
  19. 19 Apr, 2021 1 commit
  21. 16 Apr, 2021 1 commit
  23. 12 Apr, 2021 1 commit
  25. 31 Mar, 2021 1 commit
  27. 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
  29. 03 Mar, 2021 1 commit
  31. 02 Mar, 2021 1 commit
  33. 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
  35. 17 Feb, 2021 3 commits
  37. 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
  39. 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
  41. 05 Jan, 2021 1 commit
  43. 25 Nov, 2020 1 commit
  45. 23 Nov, 2020 1 commit
  47. 20 Nov, 2020 1 commit
  49. 17 Nov, 2020 1 commit
  51. 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
  53. 11 Nov, 2020 1 commit
  55. 09 Nov, 2020 1 commit
  57. 03 Nov, 2020 1 commit
  59. 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
  61. 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
  63. 15 Oct, 2020 1 commit
  65. 08 Oct, 2020 1 commit