This changelist adds the logic to format, decode, sends and receive packets in
the format specified by the GDB-remote protocol
(https://sourceware.org/gdb/onlinedocs/gdb/Overview.html#Overview).
Build with: v8_enable_wasm_gdb_remote_debugging = true
Run with: --wasm-gdb-remote
Bug: chromium:1010467
Change-Id: Ibc9c6713c561d06847b472fab591c208c193199f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1929409
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67196}
Adds an pure (not inline) assembly version of
PushAllRegistersAndIterateStack for the Microsoft Arm Assembler, which
uses slightly different syntax.
Bug: v8:10407
Change-Id: I539e2021bd86e17a2d023c061c9753b4bd96ce2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150600
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67177}
To avoid shrinking the unregister token map on each pop of the cleared
cell list, the Torque implementation of the cleanup loop avoids
shrinking the map until the end of the loop.
To support that, PopClearedCellHoldings is refactored to the Torque
PopClearedCell which calls the
JSFinalization::RemoveCellFromUnregisterTokenMap and the runtime
ShrinkFinalizationRegistryUnregisterTokenMap. The former cannot GC is
and is implemented in CSA as a fast C call. The latter can GC and is a
runtime call.
This also incidentally makes uses of FinalizationRegistry without
unregister token a fast path that doesn't have to leave Torque.
Bug: v8:8179
Change-Id: Ia0c3c5800d26e31319a818f164f6bd3267355aa6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137950
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67161}
Add ConcurrentAllocator which can be used for concurrent allocation from a background thread in the old space. ConcurrentAllocator doesn't request a GC yet when an allocation fails. This will be implemented in later CLs.
Bug: v8:10315
Change-Id: I81260ebbd8863c143e93aedb93c66d0e7c28bddb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144066
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67150}
A few notes:
1) Oilpan is a generic library, meaning that it can work with arbitrary
user types. The library is split in type-aware (include/) and
type-erased (src/) parts. The former comprises a lot of code that still
needs to be defended with dchecks;
2) Macros are prefixed with CPPGC_, so that they don't clash in the user
code with similar macros from other libraries;
3) The macros simply forward requests to V8 so that dcheck handlers can
be configured uniformly;
4) The CL doesn't contain CHECK_EQ and friends, but they can be added
later if needed.
Bug: chromium:1056170
Change-Id: I68e6f663247705233eaf030384164d81e53071e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148774
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67129}
This is a port of src/components/gc that was added recently.
Differences:
- Added back bucketing to the page pool, as that guarantees that
arenas used for specific types do not have their pages used by other
arenas.
- Replaced base::flat_map with std::map. This may cause performance
regressions when using PageMemoryRegionTree in hot paths. A
vector-like representation may be used to fix such a regression
This reverts commit a056cea51e.
Bug: chromium:1056170
Change-Id: Iffb8b0d91c8cca1815d7a1cda9486e7716aea75f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144060
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67117}
Introduce LivenessBroker which is a temporary broker object to expose
liveness during specific garbage collection phases.
This broker can be used to handle:
- PreFinalizer
- Custom weak callbacks
- Internal weak callbacks used for WeakMember
Change-Id: I3870c2b89b2538f04feabf2eb7a4676ce2fe7d61
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144059
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67107}
This reverts commit 3e1c70402e.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/12665
Original change's description:
> Reland "cppgc: Add page memory allocation backend"
>
> This is a port of src/components/gc that was added recently.
>
> Differences:
> - Added back bucketing to the page pool, as that guarantees that
> arenas used for specific types do not have their pages used by other
> arenas.
> - Replaced base::flat_map with std::map. This may cause performance
> regressions when using PageMemoryRegionTree in hot paths. A
> vector-like representation may be used to fix such a regression
>
> This reverts commit 656c68a781.
>
> Bug: chromium:1056170
> Change-Id: I638183c944255ebcaab47d2b94b1980d54479746
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2143814
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67080}
TBR=mlippautz@chromium.org,mslekova@chromium.org
Change-Id: I04b048dd979c32e9275c972307796d5f75865037
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144114
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67084}
This is a port of src/components/gc that was added recently.
Differences:
- Added back bucketing to the page pool, as that guarantees that
arenas used for specific types do not have their pages used by other
arenas.
- Replaced base::flat_map with std::map. This may cause performance
regressions when using PageMemoryRegionTree in hot paths. A
vector-like representation may be used to fix such a regression
This reverts commit 656c68a781.
Bug: chromium:1056170
Change-Id: I638183c944255ebcaab47d2b94b1980d54479746
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2143814
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67080}
This CL provides a basic allocator that allocates normal-sized objects
on pages without ever reusing them. This allows for already using the
backref from page to heap which is used in some critical places
(pre-finalizers, write barrier, Persistent).
Bug: chromium:1056170
Change-Id: Ifada9b7e984827906c267d1a3a521576587feaeb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2141736
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67076}
This reverts commit d4056c61d5.
Reason for revert: Fails on GCC, please check https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/6184
Original change's description:
> cppgc: Add page memory allocation backend
>
> This is a port of src/components/gc that was added recently.
>
> Differences:
> - Added back bucketing to the page pool, as that guarantees that
> arenas used for specific types do not have their pages used by other
> arenas.
> - Replaced base::flat_map with std::map. This may cause performance
> regressions when using PageMemoryRegionTree in hot paths. A
> vector-like representation may be used to fix such a regression
>
> Bug: chromium:1056170
> Change-Id: I03e3abe55faf7bb50c8011dafc23396889bf66db
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139586
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67073}
TBR=ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
Change-Id: I1e421898bb8a08f32d8eb2355ed547e0ee38b429
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2140949
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67074}
This is a port of src/components/gc that was added recently.
Differences:
- Added back bucketing to the page pool, as that guarantees that
arenas used for specific types do not have their pages used by other
arenas.
- Replaced base::flat_map with std::map. This may cause performance
regressions when using PageMemoryRegionTree in hot paths. A
vector-like representation may be used to fix such a regression
Bug: chromium:1056170
Change-Id: I03e3abe55faf7bb50c8011dafc23396889bf66db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139586
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67073}
This change comprises a few tiny changes wrt Member:
1) Move member policies to a separate file so that some of them
(CheckingPolicy) can be reused by Persistent;
2) SFINAE out incompatible pointers from heterogeneous ctor/asgnmt;
3) Rename kMemberSentinel to kSentinelPointer.
Bug: chromium:1056170
Change-Id: I4482998e6ba61005a5d0861dcae9fab2aa43702c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139587
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67061}
Headers containing only implementation details are better to stay in a
separate dir to indicate the user that they shouldn't be included.
Bug: chromium:1056170
Change-Id: I10f84ddf709b146396aadc820ec33bc6a49b2dac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139585
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67050}
This CL adds the necessary traits to dispatch from Member through a
visitor implementation for GarabgeCollected and GarbageCollectedMixin.
Bug: chromium:1056170
Change-Id: I12680335044aaa842639fb5e8f9a3ac61587f51a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2138431
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67041}
Assumes that (is_clang = false && is_win) => Windows native (MSVC).
Cross-compile builds will use clang and not the native tools and thus
not fall into this category.
This CL adds x86 and x64 MASM trampolines that can be used with the
native Windows toolchain (ml.exe, ml64.exe), when using is_clang =
false.
This reverts commit 8e4a5e973e.
Bug: chromium:1056170
Change-Id: I7204f15898ec5eddcc5892d4d08266a69d84ab85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139211
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67036}
This reverts commit cff2617bd1.
Reason for revert: Breaks https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/13100?
Original change's description:
> cppgc: Stack scanning support for Windows native
>
> Assumes that (is_clang = false && is_win) => Windows native (MSVC).
>
> Cross-compile builds will use clang and not the native tools and thus
> not fall into this category.
>
> This CL adds x86 and x64 MASM trampolines that can be used with the
> native Windows toolchain (ml.exe, ml64.exe), when using is_clang =
> false.
>
> Bug: chromium:1056170
> Change-Id: Ic37ce721a76ce027ebf45bef441b8fba4789dc9b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137408
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67025}
TBR=mlippautz@chromium.org,bikineev@chromium.org
Change-Id: I86286d4f438468350a81b3965956d47ae35d1c6d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2138432
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67028}
Assumes that (is_clang = false && is_win) => Windows native (MSVC).
Cross-compile builds will use clang and not the native tools and thus
not fall into this category.
This CL adds x86 and x64 MASM trampolines that can be used with the
native Windows toolchain (ml.exe, ml64.exe), when using is_clang =
false.
Bug: chromium:1056170
Change-Id: Ic37ce721a76ce027ebf45bef441b8fba4789dc9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137408
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67025}
Assumes that (is_clang = false && !is_win) => GCC or other compiler with
inline assembly that is gas-compatible.
Bug: chromium:1056170
Change-Id: I1a2a2d13b7d4af630349d9194b64394c9736ad3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137405
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67014}
Adds the PersistentHandles class, which serves as a container for
handles that can be passed back and forth between threads. Allocation
and deallocation of this class is thread-safe and the isolate tracks
all PersistentHandles containers.
Design doc: https://docs.google.com/document/d/17yKs-6apE2rGEag7tDsoyeRxg99c1dXyXQ2MfHe65tY/edit?usp=sharing
Bug: v8:10315
Change-Id: I4b9c958c9a57d755ca68862197501f75274670fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2128058
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67004}
Add support for ia32 Windows using clang. Change the callback
function from a member function to a free function. This the
compiler generating thiscall calling convention for the member
function which allows for keeping the asm trampoline uniform.
Bug: chromium:1056170
Change-Id: Ic8fcac27a628a0de026d8fe7d2e376c8f58a1737
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134136
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66975}
The difference to Chromium is that we support frame pointers and thus
integrate better with debugging in e.g. gdb.
Bug: chromium:1056170
Change-Id: I2109744d07a7b3af158ed3e0fe731f890b192eee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2129630
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66967}
Use inline asm to generate the x64 PushAllRegistersAndIterateStack
which is the trampoline for conservative stack scanning. Keep the
function definition as C code to allow clang to generate the correct
mangling for each platform.
This approach has the benefit that it immediately works for all
platforms that support clang.
Bug: chromium:1056170
Change-Id: Ic7a1c1b57e67ae1442bd8bda4e55d89112facfc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2132787
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66958}
Even though the default toolchain for assembly on Windows uses MASM
assemblers, we are not supposed to use them to support Linux/Win
cross-compile.
Bug: chromium:1056170, chromium:1066834
Change-Id: If17dbd68915f843e3fb47584560a4667d5c35bc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2132250
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66951}
Adds support for conservative stack scanning on x64. The trampolines
saving callee-saved registers are compiled using clang (non-Windows)
and MASM (Windows). This is using the default toolchain for assembly
in Chromium/V8.
This differs from Oilpan in Chromium where x86 and x64 are compiled
using NASM [1]. V8 does not yet require this dependency and building
the trampolines natively avoids it. (NASM also requires separate
blocks for x64 Windows and non-Windows.) On non-x86/x64 platforms
Chromium also uses clang, so there's little benefit in keeping the
dependency.
The trampolines are tested when building with clang.
Other platforms follow in separate CLs.
[1] https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/platform/heap/asm/SaveRegisters_x86.asm
Change-Id: Ice2e23e44391aa94147abe75ee0b5afac458b8f8
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124319
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66913}
This CL adds basic infrastructure for:
- MakeGarbageCollected
- GarbageCollected and related type traits
- Heap (API / internal)
- Basic allocation based on malloc
- CollectGarbage without marking
This allows for allocation and reclamation through an explicit GC
call. No objects are held alive from any source (stack, globals,
refs), yet.
The exact wiring of platform is future work.
Change-Id: I81b7c0ba7b525188f8c0bf9de3b7af35d34322af
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120538
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66887}
This adds HeapObjectHeader, a meta object that is put in front of
every managed object. HeapObjectHeader provides accessors for:
1. GCInfoIndex
2. In construction bit
3. size
4. Mark bit
Meta info is distributed among two uint16_t fields as (1.,2.) and
(3.,4.). This is convenient as the non-bit accessors (size,
GCInfoIndex) are constant during marking.
Object layout see heap-object-header.h.
Note: The current implementation does not bypass ASAN poisoning and
assumes an unpoisoned header whenever performing an access.
Bug: chromium:1056170
Change-Id: I753f15467ed5c2b22b47e64d3aa5a3c1baddf8e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116031
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66861}
Add LocalHandleScope to allow for local handles in LocalHeaps
(background threads). This class is similar to HandleScope which still
needs to be used on the main thread. When performing a GC, the main
thread halts all background threads at a safepoint such that it can
safely iterate their roots.
Bug: v8:10315
Change-Id: Id8f5d54cc2535e004081ccdef15dc03a39b2d0f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111218
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66853}
GCInfo and its related infrastructure is used to record information
about types. Currently, we store finalization and vtable information.
Future changes will introduce naming and tracing, similar to Oilpan in
Blink.
Information is stored in a process-wide global table that is
maintained at runtime. For static builds such information can be
recorded in the binary without the runtime overhead which is future
work.
This ports `third_party/blink/renderer/platform/heap/gc_info.{h,cc}`
on a semantic level. In addition to adjusting to V8's needs, we also
re-commit the already filled parts of the info table as read-only when
possible, making it harder to override type information.
Bug: chromium:1056170
Change-Id: Ib01eb24e6f8a94a4a647efde7af37689f8c20ba2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111214
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66847}
"By my deeds I honor him. V8."
- Add basic build files for library and unittests.
- Integrate unittests also in existing V8 unittests for simplicity.
The CL also adds FinalizerTrait and unittests to allow building a
testing target that executes code.
FinalizerTrait is used to determine how managed C++ types are
finalized. The trait should not be overridable by users but needs to
be exposed on API-level to avoid including library-internal headers.
Bug: chromium:1056170
Change-Id: I64d91053410a17a7835e50547f58990625d2da28
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108549
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66834}
This is a reland of e80ca24c80
Original change's description:
> [regexp] Rewrite error handling
>
> This patch modifies irregexp's error handling. Instead of representing
> errors as C strings, they are represented as an enumeration value
> (RegExpError), and only converted to strings when throwing the error
> object in regexp.cc. This makes it significantly easier to integrate
> into SpiderMonkey. A few notes:
>
> 1. Depending on whether the stack overflows during parsing or
> analysis, the stack overflow message can vary ("Stack overflow" or
> "Maximum call stack size exceeded"). I kept that behaviour in this
> patch, under the assumption that stack overflow messages are
> (sadly) the sorts of things that real world code ends up depending
> on.
>
> 2. Depending on the point in code where the error was identified,
> invalid unicode escapes could be reported as "Invalid Unicode
> escape", "Invalid unicode escape", or "Invalid Unicode escape
> sequence". I fervently hope that nobody depends on the specific
> wording of a syntax error, so I standardized on the first one. (It
> was both the most common, and the most consistent with other
> "Invalid X escape" messages.)
>
> 3. In addition to changing the representation, this patch also adds an
> error_pos field to RegExpParser and RegExpCompileData, which stores
> the position at which an error occurred. This is used by
> SpiderMonkey to provide more helpful messages about where a syntax
> error occurred in large regular expressions.
>
> 4. This model is closer to V8's existing MessageTemplate
> infrastructure. I considered trying to integrate it more closely
> with MessageTemplate, but since one of our stated goals for this
> project was to make it easier to use irregexp outside of V8, I
> decided to hold off.
>
> R=jgruber@chromium.org
>
> Bug: v8:10303
> Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66784}
R=jgruber@chromium.org
Bug: v8:10303
Change-Id: Iad1f11a0e0b9e525d7499aacb56c27eff9e7c7b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2109952
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66798}
This implements the first part of WebAssembly debug evaluate. The patch
includes the foundation required to execute evaluator modules. It only
implements the first of the APIs of the evaluator module spec.
Bug: chromium:1020120
Change-Id: I06ec98a63d0a0ec8d81c2eac4319c4b85d3e16c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089936
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66787}
This reverts commit e80ca24c80.
Reason for revert: Causes failures in the fast/regex/non-pattern-characters.html Blink web test (https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3679)
Original change's description:
> [regexp] Rewrite error handling
>
> This patch modifies irregexp's error handling. Instead of representing
> errors as C strings, they are represented as an enumeration value
> (RegExpError), and only converted to strings when throwing the error
> object in regexp.cc. This makes it significantly easier to integrate
> into SpiderMonkey. A few notes:
>
> 1. Depending on whether the stack overflows during parsing or
> analysis, the stack overflow message can vary ("Stack overflow" or
> "Maximum call stack size exceeded"). I kept that behaviour in this
> patch, under the assumption that stack overflow messages are
> (sadly) the sorts of things that real world code ends up depending
> on.
>
> 2. Depending on the point in code where the error was identified,
> invalid unicode escapes could be reported as "Invalid Unicode
> escape", "Invalid unicode escape", or "Invalid Unicode escape
> sequence". I fervently hope that nobody depends on the specific
> wording of a syntax error, so I standardized on the first one. (It
> was both the most common, and the most consistent with other
> "Invalid X escape" messages.)
>
> 3. In addition to changing the representation, this patch also adds an
> error_pos field to RegExpParser and RegExpCompileData, which stores
> the position at which an error occurred. This is used by
> SpiderMonkey to provide more helpful messages about where a syntax
> error occurred in large regular expressions.
>
> 4. This model is closer to V8's existing MessageTemplate
> infrastructure. I considered trying to integrate it more closely
> with MessageTemplate, but since one of our stated goals for this
> project was to make it easier to use irregexp outside of V8, I
> decided to hold off.
>
> R=jgruber@chromium.org
>
> Bug: v8:10303
> Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66784}
TBR=jgruber@chromium.org,iireland@mozilla.com
Change-Id: I9247635f3c5b17c943b9c4abaf82ebe7b2de165e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10303
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108550
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66786}
This patch modifies irregexp's error handling. Instead of representing
errors as C strings, they are represented as an enumeration value
(RegExpError), and only converted to strings when throwing the error
object in regexp.cc. This makes it significantly easier to integrate
into SpiderMonkey. A few notes:
1. Depending on whether the stack overflows during parsing or
analysis, the stack overflow message can vary ("Stack overflow" or
"Maximum call stack size exceeded"). I kept that behaviour in this
patch, under the assumption that stack overflow messages are
(sadly) the sorts of things that real world code ends up depending
on.
2. Depending on the point in code where the error was identified,
invalid unicode escapes could be reported as "Invalid Unicode
escape", "Invalid unicode escape", or "Invalid Unicode escape
sequence". I fervently hope that nobody depends on the specific
wording of a syntax error, so I standardized on the first one. (It
was both the most common, and the most consistent with other
"Invalid X escape" messages.)
3. In addition to changing the representation, this patch also adds an
error_pos field to RegExpParser and RegExpCompileData, which stores
the position at which an error occurred. This is used by
SpiderMonkey to provide more helpful messages about where a syntax
error occurred in large regular expressions.
4. This model is closer to V8's existing MessageTemplate
infrastructure. I considered trying to integrate it more closely
with MessageTemplate, but since one of our stated goals for this
project was to make it easier to use irregexp outside of V8, I
decided to hold off.
R=jgruber@chromium.org
Bug: v8:10303
Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66784}
Generate a BTI instruction at each target of an indirect branch
(BR/BLR). An indirect branch that doesn't jump to a BTI instruction
will generate an exception on a BTI-enabled core. On cores that do
not support the BTI extension, the BTI instruction is a NOP.
Targets of indirect branch instructions include, among other things,
function entrypoints, exception handlers and jump tables. Lazy deopt
exits can potentially be reached through an indirect branch when an
exception is thrown, so they also get an additional BTI instruction.
Bug: v8:10026
Change-Id: I0ebf51071f1b604f60f524096e013dfd64fcd7ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967315
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66751}
Add safepoint mechanism to stop concurrent threads and bring them to a
safepoint. Threads are stopped before the safepoint and after e.g. the
GC resumed again. Each thread needs to be stopped in a safepoint, such
that all roots can be iterated safely.
Running threads need to be cooperative and are required to perform
regular safepoint polls.
The last version of this CL was reverted because safepoint_requested_
wasn't initialized (see https://crrev.com/c/2105634).
Bug: v8:10315
Change-Id: I6ef244c0fb31c178589b5e3d1c62687a8dd65768
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105635
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66732}
This reverts commit c84963eaa7.
Reason for revert: Fails on msan: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/31376
Original change's description:
> [heap] Introduce safepoint mechanism
>
> Add safepoint mechanism to stop concurrent threads and bring them to a
> safepoint. Threads are stopped before the safepoint and after e.g. the
> GC resumed again. Each thread needs to be stopped in a safepoint, such
> that all roots can be iterated safely.
>
> Running threads need to be cooperative and are required to perform
> regular safepoint polls.
>
> Bug: v8:10315
> Change-Id: I47f07e7d2ef5bc5adbba6b9e8e79a1f0f45b97ad
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102578
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66727}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: If11281b2b9fc622b91261417b202676f23f60b50
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105634
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66729}
Add safepoint mechanism to stop concurrent threads and bring them to a
safepoint. Threads are stopped before the safepoint and after e.g. the
GC resumed again. Each thread needs to be stopped in a safepoint, such
that all roots can be iterated safely.
Running threads need to be cooperative and are required to perform
regular safepoint polls.
Bug: v8:10315
Change-Id: I47f07e7d2ef5bc5adbba6b9e8e79a1f0f45b97ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102578
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66727}
The set of registers to spill was wrong. Instead of spilling wasm
parameter registers (like the WasmCompileLazy builtin), we should spill
all registers that are being used as Liftoff cache registers.
This CL defines platform-specific WasmDebugBreakFrameConstants which
hold the set of registers to spill. This set is used in the builtin, and
will later be used for inspecting the spilled registers.
In order to iterate bit sets more easily in both direction (MSB to LSB
or LSB to MSB), we add a base::bits::IterateBits{,Backwards} method
which provides the respective iterators.
R=jkummerow@chromium.orgCC=thibaudm@chromium.org
Bug: v8:10222
Change-Id: I73ecbdff9b29e244c478b404063c0c9ee25bc821
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102570
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66715}
Instead of directly using the Heap class concurrent threads will use the
LocalHeap class for all heap operations.
Bug: v8:10315
Change-Id: Ie007abb5b914af7f2507c9e790f34baacbcdf588
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096620
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66663}
