I've noticed a few places where class fields as defined in Torque have
different names than the corresponding accessors in the C++ class. I
think they should match. Most of this change is just mechanically
updating the various places that use k##Field##Offset for those fields.

Change-Id: I8ba52aed7f6a1cd6b2d71158f71150b66c2c0da0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027263
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75796}

This CL adds features to pack/unpack map words.

Currently V8 cannot store extra metadata in object headers -- because V8
objects do not have a proper header, but only a map pointer at the start
of the object. To store per-object metadata like marking data, a side
table is required as the per-object metadata storage.

This CL enables V8 to use higher unused bits in a 64-bit map word as
per-object metadata storage. Map pointer stores come with an extra step
to encode the metadata into the pointer (we call it "map packing").
Map pointer loads will also remove the metadata bits as well (we call it
"map packing").

Since the map word is no longer a valid pointer after packing, we also
change the tag of the packed map word to make it looks like a Smi. This
helps various GC and barrier code to correctly skip them instead of
blindly dereferencing this invalid pointer.

A ninja flag `v8_enable_map_packing` is provided to turn this
map-packing feature on and off. It is disabled by default.

* Only works on x64 platform, with `v8_enable_pointer_compression`
  set to `false`

Bug: v8:11624
Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73915}

This removes the heap sandbox's dependency on being able to reconstruct
an Isolate from the pointer cage base address.

Bug: v8:11460
Change-Id: I501ace5b83a2cefdf717de0d7387fd816edfb3f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783673
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73887}

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: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73795}

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: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73793}

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: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73792}

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}

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}

This is a reland of 19b62d0b

Fixing the misalignment issue founded in usban build by doing four-byte
comparison: compressing the "expected" values such as script.name() and
passing them to CheckProp as type Tagged_t

Original change's description:
> [v8windbg] Add more items in the Locals pane
>
> Add more items in the Locals pane representing the JS function name,
> source file name, and character offset within the source file, so
> that the user doesn’t need to dig through the shared_function_info to
> find them.
>
> Change-Id: I5d42b3c9542885a72e81613503d1d5abf51870b5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712310
> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#73282}

Change-Id: Idd77f61905651fbcfae5f5b590094639bc205834
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2744959Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#73359}

This reverts commit 19b62d0b.

Reason for revert: Undefined behavior
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/15449

Original change's description:
> [v8windbg] Add more items in the Locals pane
>
> Add more items in the Locals pane representing the JS function name,
> source file name, and character offset within the source file, so
> that the user doesn’t need to dig through the shared_function_info to
> find them.
>
> Change-Id: I5d42b3c9542885a72e81613503d1d5abf51870b5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712310
> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#73282}

Change-Id: I616cd642379b97dff5fb0c66aeb6488e2f9b298b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2744420
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73284}

Add more items in the Locals pane representing the JS function name,
source file name, and character offset within the source file, so
that the user doesn’t need to dig through the shared_function_info to
find them.

Change-Id: I5d42b3c9542885a72e81613503d1d5abf51870b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712310
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#73282}

Split out all the headers from v8_compiler/v8_compiler_opt and
v8_base_without_compiler into v8_internal_headers since the headers
have inter-dependencies that otherwise make it impossible to satisfy gn
check.

Also adds new v8_header_set torque_runtime_support that exports
src/torque/runtime-support.h separately from the generated headers.

This reduces the number of gn check failures from 169 to 59.

Bug: v8:7330
Change-Id: Ie7ebc894910b7efa02011a74da964e11995c7f4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712569
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73104}

Currently if gn check is enabled (with v8/third_party ignored), there
are many errors due to headers being used without adding the proper
dependency in BUILD.gn (or because it's being used transitively without
a public_deps chain).

This makes the number of errors go from 2114 to 195.

Apart from adding dependencies, it also moves _v8_internal_Node_Print
from objects-printer.cc to node.cc so it can see the Node::Print method
which wouldn't otherwise be possible without a circular dependency. Also
removes the previously deleted compiler/graph-builder-tester.h file.

Bug: v8:7330
Change-Id: Icb34585fbef621588265cf4267cfc88ecbcf0a72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2702331Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72908}

Bug: chromium:1006541
Change-Id: Ia3f1b16a4becd10bd4041f35e125aad7acc33949
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653235
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72386}

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: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72187}

Docs: https://docs.google.com/document/d/13n1qaB6A-gvgWc9NDhWm-UPuOqow_Y0DNgCeTbtIotI

Modify that C++ backend so that it can emit either runtime C++ or
postmortem debugging code. When in postmortem debugging mode, the
overall code structure would look similar with some difference:
1. Instead of passing an Isolate* everywhere, we pass a MemoryAccessor.
2. Instead of runtime class names like String, we use uintptr_t
3. When loading data from objects, instead of TaggedField<T>::load or
Object::ReadField (which read from the current process), we use the
MemoryAccessor and read data from the debuggee process.
4. Return values should be wrapped in the Value struct.

Implement the debug accessors for complex length expressions and add
test for such class (SmallOrderedHashSet).

Change-Id: I34107c92b31ed4e07bb628ae58c84487e41ba648
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477921
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72148}

Bug: v8:11074
Change-Id: I108a847e12df2438cc73e4f7a31ba4148f07cdc0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569562
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71593}

This reverts commit 3c49308a.

Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Clusterfuzz%20Mac64%20ASAN%20-%20debug%20builder/18360

Original change's description:
> [DEPS] Add abseil to deps
>
> Add a dependency on the chromium abseil-cpp subdir mirror.
>
> Bug: v8:11006
> Change-Id: Icaad757269d27c65bc368ed539f84c5bb79ee62d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464940
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70786}

TBR=rmcilroy@chromium.org,adamk@chromium.org,yangguo@chromium.org,hpayer@chromium.org,leszeks@chromium.org,victorgomes@chromium.org

Change-Id: Iff2ac3b0da8725ec2df69aa527e5a4255ca3009c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11006
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2501843Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70787}

Add a dependency on the chromium abseil-cpp subdir mirror.

Bug: v8:11006
Change-Id: Icaad757269d27c65bc368ed539f84c5bb79ee62d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464940
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70786}

This change tags pointers in the external pointer table with a type
dependent value in order to prevent type confusions between different
external pointers.

Bug: v8:10391
Change-Id: I5a83178e5ac46d49a99c91047816926120d801d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2443133Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Samuel Groß <saelo@google.com>
Cr-Commit-Position: refs/heads/master@{#70430}

Introduce an IsolateRoot class, which encapsulates the root address
needed for pointer decompression. This class is implicitly constructible
from both Isolate* and LocalIsolate*, allowing us to avoid templating
methods that can take both, or awkwardly creating a `const Isolate*`
from a `LocalIsolate*` just for getters.

Change-Id: I6d4b9492409fc7d5b375162e381192cb48c8ba01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440605
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70365}

This is a reland of 64caf2b0

Original change's description:
> [torque] refactor: use -tq only in filenames derived from .tq files
>
> This is to establish a naming rule for Torque-generated files:
> - If the file is called foo/bar-tq..., then it is derived from a
>   file foo/bar.tq
> - Otherwise it doesn't belong to a specific .tq file.
>
> So far, we attached -tq to all Torque-generated file names, where it
> sometimes corresponded to a .tq file name and sometimes not.
> It is not necessary to add -tq to file names to indicate that they are
> Torque-generated, since they are already in a directory called
> torque-generated, and we always refer to them as
> "torque-generated/filename", so there is no confusion even though some
> files now have the same name as a corresponding hand-written file, for
> example factory.cc.
>
> TBR: hpayer@chromium.org
> Bug: v8:7793
> Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70060}

Bug: v8:7793
TBR: hpayer@chromium.org jgruber@chromium.org
Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70137}

This reverts commit 64caf2b0.

Reason for revert: Seems to be causing a failure:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?

Original change's description:
> [torque] refactor: use -tq only in filenames derived from .tq files
> 
> This is to establish a naming rule for Torque-generated files:
> - If the file is called foo/bar-tq..., then it is derived from a
>   file foo/bar.tq
> - Otherwise it doesn't belong to a specific .tq file.
> 
> So far, we attached -tq to all Torque-generated file names, where it
> sometimes corresponded to a .tq file name and sometimes not.
> It is not necessary to add -tq to file names to indicate that they are
> Torque-generated, since they are already in a directory called
> torque-generated, and we always refer to them as
> "torque-generated/filename", so there is no confusion even though some
> files now have the same name as a corresponding hand-written file, for
> example factory.cc.
> 
> TBR: hpayer@chromium.org
> Bug: v8:7793
> Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70060}

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

Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70065}

This is to establish a naming rule for Torque-generated files:
- If the file is called foo/bar-tq..., then it is derived from a
  file foo/bar.tq
- Otherwise it doesn't belong to a specific .tq file.

So far, we attached -tq to all Torque-generated file names, where it
sometimes corresponded to a .tq file name and sometimes not.
It is not necessary to add -tq to file names to indicate that they are
Torque-generated, since they are already in a directory called
torque-generated, and we always refer to them as
"torque-generated/filename", so there is no confusion even though some
files now have the same name as a corresponding hand-written file, for
example factory.cc.

TBR: hpayer@chromium.org
Bug: v8:7793
Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70060}

Change-Id: I65ed798968b602891e7f8d13c08c9065ab58d6d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418367Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70031}

For js frame, we want to display currently executing function.

Change-Id: If33b04279dafdf6e4834bfb6c7240e8e7e799fc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411483Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70018}

While the sampler checked if the sampled thread had the Isolate locked
(if locks are being used) under Linux, the check was not done under
Windows (or Fuchsia) which meant that in a multi-threading application
under Windows, thread locking was not checked making it prone to seg
faults and the like as the profiler would be using isolate->js_entry_sp
to determine the stack to walk but isolate->js_entry_sp is the stack
pointer for the thread that currently has the Isolate lock so, if the
sampled thread does not have the lock, the sampler woud be iterating
over the wrong stack, one that might actually be actively changing on
another thread. The fix was to move the lock check into CpuSampler
and Ticker (--prof) so all OSes would do the correct check.

The basic concept is that on all operating systems a CpuProfiler, and
so its corresponding CpuCampler, the profiler is tied to a thread.
This is not based on first principles or anything, it's simply the
way it works in V8, though it is a useful conceit as it makes
visualization and interpretation of profile data much easier.

To collect a sample on a thread associated with a profiler the thread
must be stopped for obvious reasons -- walking the stack of a running
thread is a formula for disaster. The mechanism for stopping a thread
is OS-specific and is done in sample.cc. There are currently three
basic approaches, one for Linux/Unix variants, one for Windows and one
for Fuchsia. The approaches vary as to which thread actually collects
the sample -- under Linux the sample is actually collected on the
(interrupted) sampled thread whereas under Fuchsia/Windows it's on
a separate thread.

However, in a multi-threaded environment (where Locker is used), it's
not sufficient for the sampled thread to be stopped. Because the stack
walk involves looking in the Isolate heap, no other thread can be
messing with the heap while the sample is collected. The only ways to
ensure this would be to either stop all threads whenever collecting a
sample, or to ensure that the thread being sampled holds the Isolate
lock so prevents other threads from messing with the heap. While there
might be something to be said for the "stop all threads" approach, the
current approach in V8 is to only stop the sampled thread so, if in a
multi-threaded environment, the profiler must check if the thread being
sampled holds the Isolate lock.

Since this check must be done, independent of which thread the sample
is being collected on (since it varies from OS to OS), the approach is
to save the thread id of the thread to be profiled/sampled when the
CpuSampler is instantiated (on all OSes it is instantiated on the
sampled thread) and then check that thread id against the Isolate lock
holder thread id before collecting a sample. If it matches, we know
sample.cc has stop the sampled thread, one way or another, and we know
that no other thread can mess with the heap (since the stopped thread
holds the Isolate lock) so it's safe to walk the stack and collect data
from the heap so the sample can be taken. It it doesn't match, we can't
safely collect the sample so we don't.

Bug: v8:10850
Change-Id: Iba6cabcd3e11a19c261c004103e37e806934dc6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411343Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69952}

tools/debug_helper:run_mkgrokdump used to only depend on mkgrokdump.
However, the snapshot can change without affecting the mkgrokdump
binary itself. So, if the mkgrokdump binary doesn't change, then
run_mkgrokdump doesn't run, even if the snapshot changed.

This could cause mysterious test failures in incremental builds, in
particular for tests testing the contents of heap-constants-gen.cc.

Now, we make run_mkgrokdump depend on run_mksnapshot_default
directly, so that snapshot updates force an mkgrokdump run.

Change-Id: Ia3871e1b4fa15ec2dbc0bc5463afdb427cb39c61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400987
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69776}

Cast resource field in ExternalString as

v8: :String::ExternalStringResourceBase* would give us more info.
Change-Id: Iae97b477f400f58365e2381b7230d2226d490aa7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388742
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69734}

This reverts commit dfb3f7da.

Reason for revert: Breaks LSAN & ASAN flakily: https://bugs.chromium.org/p/v8/issues/detail?id=10861

Original change's description:
> [cpu-profiler] Ensure sampled thread has Isolate lock under Windows
> 
> While the sampler checked if the sampled thread had the Isolate locked
> (if locks are being used) under Linux, the check was not done under
> Windows (or Fuchsia) which meant that in a multi-threading application
> under Windows, thread locking was not checked making it prone to seg
> faults and the like as the profiler would be extracting info from a
> heap in motion. The fix was to move the lock check into CpuSampler
> and Ticker (--prof) so all OSes would do the correct check.
> 
> The basic concept is that on all operating systems a CpuProfiler, and
> so its corresponding CpuCampler, the profiler is tied to a thread.
> This is not based on first principles or anything, it's simply the
> way it works in V8, though it is a useful conceit as it makes
> visualization and interpretation of profile data much easier.
> 
> To collect a sample on a thread associated with a profiler the thread
> must be stopped for obvious reasons -- walking the stack of a running
> thread is a formula for disaster. The mechanism for stopping a thread
> is OS-specific and is done in sample.cc. There are currently three
> basic approaches, one for Linux/Unix variants, one for Windows and one
> for Fuchsia. The approaches vary as to which thread actually collects
> the sample -- under Linux the sample is actually collected on the
> (interrupted) sampled thread whereas under Fuchsia/Windows it's on
> a separate thread.
> 
> However, in a multi-threaded environment (where Locker is used), it's
> not sufficient for the sampled thread to be stopped. Because the stack
> walk involves looking in the Isolate heap, no other thread can be
> messing with the heap while the sample is collected. The only ways to
> ensure this would be to either stop all threads whenever collecting a
> sample, or to ensure that the thread being sampled holds the Isolate
> lock so prevents other threads from messing with the heap. While there
> might be something to be said for the "stop all threads" approach, the
> current approach in V8 is to only stop the sampled thread so, if in a
> multi-threaded environment, the profiler must check if the thread being
> sampled holds the Isolate lock.
> 
> Since this check must be done, independent of which thread the sample
> is being collected on (since it varies from OS to OS), the approach is
> to save the thread id of the thread to be profiled/sampled when the
> CpuSampler is instantiated (on all OSes it is instantiated on the
> sampled thread) and then check that thread id against the Isolate lock
> holder thread id before collecting a sample. If it matches, we know
> sample.cc has stop the sampled thread, one way or another, and we know
> that no other thread can mess with the heap (since the stopped thread
> holds the Isolate lock) so it's safe to walk the stack and collect data
> from the heap so the sample can be taken. It it doesn't match, we can't
> safely collect the sample so we don't.
> 
> Bug: v8:10850
> Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69623}

TBR=akodat@rocketsoftware.com,petermarshall@chromium.org,petermarshall@google.com

Change-Id: Ib6b6dc4ce109d5aa4e504fa7c9769f5cd95ddd0c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10850
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387570Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69638}

While the sampler checked if the sampled thread had the Isolate locked
(if locks are being used) under Linux, the check was not done under
Windows (or Fuchsia) which meant that in a multi-threading application
under Windows, thread locking was not checked making it prone to seg
faults and the like as the profiler would be extracting info from a
heap in motion. The fix was to move the lock check into CpuSampler
and Ticker (--prof) so all OSes would do the correct check.

The basic concept is that on all operating systems a CpuProfiler, and
so its corresponding CpuCampler, the profiler is tied to a thread.
This is not based on first principles or anything, it's simply the
way it works in V8, though it is a useful conceit as it makes
visualization and interpretation of profile data much easier.

To collect a sample on a thread associated with a profiler the thread
must be stopped for obvious reasons -- walking the stack of a running
thread is a formula for disaster. The mechanism for stopping a thread
is OS-specific and is done in sample.cc. There are currently three
basic approaches, one for Linux/Unix variants, one for Windows and one
for Fuchsia. The approaches vary as to which thread actually collects
the sample -- under Linux the sample is actually collected on the
(interrupted) sampled thread whereas under Fuchsia/Windows it's on
a separate thread.

However, in a multi-threaded environment (where Locker is used), it's
not sufficient for the sampled thread to be stopped. Because the stack
walk involves looking in the Isolate heap, no other thread can be
messing with the heap while the sample is collected. The only ways to
ensure this would be to either stop all threads whenever collecting a
sample, or to ensure that the thread being sampled holds the Isolate
lock so prevents other threads from messing with the heap. While there
might be something to be said for the "stop all threads" approach, the
current approach in V8 is to only stop the sampled thread so, if in a
multi-threaded environment, the profiler must check if the thread being
sampled holds the Isolate lock.

Since this check must be done, independent of which thread the sample
is being collected on (since it varies from OS to OS), the approach is
to save the thread id of the thread to be profiled/sampled when the
CpuSampler is instantiated (on all OSes it is instantiated on the
sampled thread) and then check that thread id against the Isolate lock
holder thread id before collecting a sample. If it matches, we know
sample.cc has stop the sampled thread, one way or another, and we know
that no other thread can mess with the heap (since the stopped thread
holds the Isolate lock) so it's safe to walk the stack and collect data
from the heap so the sample can be taken. It it doesn't match, we can't
safely collect the sample so we don't.

Bug: v8:10850
Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69623}

Get value from type payload, check and show bitset name.

Change-Id: I6d0e0f30fca0b2aaddfd5f18abf948886552f2dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2258815
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#68495}

This CL adds 2 new values to the EmbedderStackState enum with more
explicit names. The old values are updated as aliases to the new
values and marked as soon to be deprecated. This CL also moves the
enum to v8-platform.h so that it can be reused by cppgc.

Depracating individual values in an enum is supported by GCC only
since version 6. Thus new macros were needed for the deprecation
(which delegate to the existing macros when supported). GCC versions
older than 6 are still used by the CQ bots.

Bug: chromium:1056170
Change-Id: Id1ea73edfbbae282b0d8a3bb103dbbbf8ebd417e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2188971
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67744}

Bug: v8:10391
Change-Id: I4e86394c53d02eab797c2daad2ccfde6acb83bf0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151350
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67619}

This patch replaces V8's tracing implementation (i.e., the TRACE_EVENT
macros) with the track event base implementation from Perfetto. The
advantages of doing this are:

1) This allows us to remove most tracing-related backend code from V8.

2) V8 can start writing strongly typed trace event arguments, which
   are more compact, easier to process and more extensible than legacy
   JSON-based trace arguments.

For the time being, we still support the old trace macros when V8 is
embedded into Chrome and other embedders.

Design doc: https://docs.google.com/document/d/1f7tt4cb-JcA5bQFR1oXk60ncJPpkL02_Hi_Bc6MfTQk/edit#heading=h.398p6b4eaen2

Bug: chromium:1006766
Change-Id: Ie71474fbe065821772b13d851487ebbca680c4ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1947688
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67217}

Bill kindly pointed out to me that v8windbg was not handling bit_field2
correctly. The issue was that the constexpr type for ElementsKind was,
somewhat unsurprisingly, "ElementsKind", but v8windbg expected a fully-
qualified type name like "v8::internal::ElementsKind". This change
addresses the problem in two ways:
1. Update v8windbg's type resolution logic to resolve type names as if
   they were used in the v8::internal namespace. This makes it more
   consistent with how those type names are used in other generated
   Torque code, reducing surprises and the number of times we have to
   write `v8::internal::` in .tq files.
2. Add compile-time verification that any constexpr type name used as a
   string in class-debug-readers-tq.cc can also resolve as a type name.

Bug: v8:9376
Change-Id: I349cd6ab586fd8345a1fa8bfc3989bb8e6376ab8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063769Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66633}

In the process:

* Augment C++-generated Torque classes with SizeFor methods to
  calculate size of instances.

* Add a new "@generateBodyDescriptor" annotation that causes Torque to
  generate C++ BodyDescriptors code that can be used to visit objects
  compatible with existing V8 mechanisms, e.g. GC

* Fully automate C++ macro machinery so that adding non-extern Torque
  class doesn't require any C++ changes, including ensuring generation
  of instance types and proper boilerplate for validators and
  printers.

* Make handling of @export a true annotation, allowing the modifier to
  be used on class declarations.

* Add functionality such that classes with the @export annotation are
  available to be used from C++. Field accessors for exported classes
  are public and factory methods are generated to create instances of
  the objects from C++.

* Change the Torque compiler such that Non-exported classes implicitly
  have the @generateBodyDescriptor annotation added and causes both
  verifiers and printers to be generated.

* Switch non-extern Torque classes from using existing Struct-based
  machinery to being first-class classes that support more existing
  Torque class features.

Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66621}

This fixes a build break in certain configurations. v8_debug_helper
depends on generate_bytecode_builtins_list via the following headers:

In file included from gen/v8/tools/debug_helper/heap-constants-gen.cc:5:
In file included from ../../v8\src/common/ptr-compr-inl.h:10:
In file included from ../../v8\src/execution/isolate.h:19:
In file included from ../../v8\src/builtins/builtins.h:9:

Change-Id: I38e5d851afc6ce52716d3e5e64ae9219df396bd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078768
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66517}

This change adds support for the postmortem inspection library to show
the content of cached external strings if that content is available. It
also fixes a minor annoyance where strings with unavailable data would
show up as "...". Now, if fetching the very first character fails, we
omit the literal value from the output.

Bug: v8:9376
Change-Id: Id694a774c231ab3467fb59b1c149284729acfb20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1987922Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65961}

This change updates GetObjectProperties to list all of the bitfields
within a class field, if that class field's type is a bitfield struct.
The representation of bitfields in the GetObjectProperties response is
very similar to the representation of struct fields, but with two extra
bytes of data specifying the shift and size of the bitfield.

Bug: v8:9376
Change-Id: I40a22169f3d01652a7f2db8cface43c2a1e30cfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960835Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65610}