Commit Graph

1181 Commits

Author SHA1 Message Date
Jakob Gruber
0a6c1a778a Remove the turboprop implementation
Bug: v8:12552
Change-Id: I99e4d8e8aeba5460f11e54cc1b2bcaea98a5276d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400964
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78698}
2022-01-20 12:31:39 +00:00
Dominik Inführ
88ecbf26fb [heap] Refactor MemoryAllocator
This CL doesn't change behavior, only refactors MemoryAllocator:

* De-templatify class, MemoryAllocator is used on slow path and doesn't
  really need templates for performance.
* Rename FreeMode names
* Move methods into private section of class

Change-Id: I7894fba956dcd7aa78ad0284d0924662fef4acae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379812
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78580}
2022-01-12 09:53:53 +00:00
Benedikt Meurer
765ca6a0d3 [inspector] Capture stack trace only once for JSError objects.
When creating a new JSError object (or using the non-standard API
`Error.captureStackTrace`) V8 would previously capture the "simple stack
trace" (as FixedArray of CallSiteInfo instances) to be used for the non-
standard `error.stack` property, and if the inspector was active also
capture the "detailed stack trace" (as FixedArray of StackFrameInfo
instances). This turns out to be quite a lot of overhead, both in terms
of execution time as well as memory pressure, especially since the
information needed for the inspector is a proper subset of the
information needed by `error.stack`.

So this CL addresses the above issue by capturing only the "simple stack
trace" (in the common case) and computing the "detailed stack trace"
from the "simple stack trace" when on demand. This is accomplished by
introducing a new ErrorStackData container that is used to store the
stack trace information on JSErrors when the inspector is active. When
capturing stack trace for a JSError object while the inspector is
active, we take the maximum of the program controlled stack trace limit
and the inspector requested stack trace limit, and memorize the program
controlled stack trace limit for later formatting (to ensure that the
presence of the inspector is not observable by the program).

On the `standalone.js` benchmark from crbug.com/1283162 (with the
default max call stack size of 200) we reduce execution time by around
16% compared to ToT. And compared to V8 9.9.4 (the version prior to the
regression in crbug.com/1280831), we are 6% faster now.

Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Bug: chromium:1280831, chromium:1278650, chromium:1258599
Bug: chromium:1280803, chromium:1280832, chromium:1280818
Fixed: chromium:1283162
Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78542}
2022-01-10 14:55:18 +00:00
Igor Sheludko
b5fabce811 [ext-code-space][cleanup] Remove CodeDataContainer table
This CL
* removes Builtins::codet() and Builtins::codet_handle() returning
  builtins as CodeT objects in favor of code() and code_handle(),
* removes BUILTIN_CODET macro in favor of BUILTIN_CODE,
* removes CodeDataContainer table.

Bug: v8:11880
Change-Id: Ic868549030744b0ff3ea5d5edbfcacf77c6de96d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3344650
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78399}
2021-12-16 17:32:39 +00:00
Igor Sheludko
a7db5fcbad [ext-code-space][compiler] Support calling CodeT targets
... in order to avoid Code <-> CodeT conversions in builtins.
This CL changes the meaning of RelocInfo::CODE_TARGET which now expects
CodeT objects as a code target.

In order to reduce code churn this CL makes BUILTIN_CODE and friends
return CodeT instead of Code. In the follow-up CLs BUILTIN_CODET and
friends will be removed.

Bug: v8:11880
Change-Id: Ib8f60973e55c60fc62ba84707471da388f8201b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338483
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78393}
2021-12-16 13:45:12 +00:00
Igor Sheludko
a0108291e2 [ext-code-space] Avoid Code <-> CodeT conversions in runtime, pt.2
This CL migrates JSFunction's code accessors to CodeT.

Bug: v8:11880
Change-Id: I8cf367eb79cc1d59548dd4f3e18c010f76f101cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3330466
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78365}
2021-12-14 12:19:05 +00:00
Benedikt Meurer
4ecf143801 [refactor] Rename StackFrameInfo to CallSiteInfo.
This is the second step in the refactoring to make v8::StackFrame
more lightweight and usable for (long time storage) by the V8
inspector (see https://bit.ly/v8-stack-frame for an overview).

This is a purely mechanical change without any functional aspects.
The intention is to make the use case for the CallSiteInfo objects
clear, namely to serve as the backing store for the CallSite objects
exposed via the Error.prepareStackTrace() API and used under the
hood to implement the error.stack accessor.

Doc: https://bit.ly/v8-stack-frame
Bug: chromium:1258599, chromium:1278647, chromium:1278650
Change-Id: I39dffd1f1a8e5158ddc56f2a0a2b1b28321f487a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300138
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78361}
2021-12-14 10:03:25 +00:00
Dominik Inführ
ce9453bb46 [heap] Find references in client heaps to shared objects in shared GC
When performing a shared GC, we need to find references from the client
heaps into the shared heaps. For now we achieve this by simply
iterating all objects in client heaps.

We need to do this both for marking and when updating pointers after
evacuation.

Bug: v8:11708
Change-Id: Ic1dd94cc352be0404095e548979c37b1ef25682a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300142
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78240}
2021-12-06 12:00:18 +00:00
Michael Lippautz
05b241c649 heap: Remove unused Worklist
- Removes the unused Worklist implementation. All uses now refer to
  ::heap::base::Worklist.
- Renames CppgcWorklistTest -> WorklistTest
- Add test for Swap()

Bug: v8:12426
Change-Id: I62c3472c030b853a846cf13ab48597ea1af8f700
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306507
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78208}
2021-12-02 12:43:01 +00:00
Nikolaos Papaspyrou
427a67993c heap: Place LABs in IsolateData
Until now, LABs were accessed from generated code via external
references, e.g., see NewSpaceAllocationTopAddress() and
NewSpaceAllocationLimitAddress().

This patch places them in the IsolateData, so they can be accessed
using Isolate-constant offsets. It affects the hot path of all TF
generated code.

Bug: v8:12428
Change-Id: I7bfd54bea4febead404829d8e0b058b6cf53a374
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3303800
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78176}
2021-12-01 08:51:33 +00:00
Camillo Bruni
44166c6091 [api] V8::Initialize cleanup
- V8::Deprecate ShutdownPlatform in favor of V8::DisposePlatform
- Rename i::V8::TearDown to i::V8::Dispose
- Clean up i::V8::Initialize
- Remove needless V8::Initialize() calls in cctests
- Remove CcTest::DisableAutomaticDispose()
- Add checks to Isolate::Allocate and Isolate::Dispose that there is
  and active platform

Change-Id: Iac84f9ade9d1781e9e8b8c88ea8fe74013f51c4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306482
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78162}
2021-11-30 14:30:38 +00:00
Igor Sheludko
2aa8722d9c [ext-code-space] Use cage-friendly HeapObject::map() in GC
... and thus avoid the need for special handling of objects located
in external code space.

This will also allow making HeapObject::IsBlah() checks faster when
external code space is enabled.

Bug: v8:11880
Change-Id: I12d07c05451ff198f0a6182d9b5849f76015e7fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300140
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78104}
2021-11-26 11:56:00 +00:00
Ng Zhi An
50c808d4b3 [cleanup] Fix -Wshadow warnings
Bug: v8:12244,v8:12245
Change-Id: I816930bfc65a2e597a41562cb115af5d0bca199b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3296147
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78047}
2021-11-23 17:32:04 +00:00
Jakob Gruber
a462665457 Disable --stress-concurrent-inlining in various tests
test-heap/NextCodeLinkIsWeak
test-heap/NextCodeLinkIsWeak2
test-heap/NextCodeLinkInCodeDataContainerIsCleared

These tests depends on deterministic compile job behavior.

Fixed: v8:12367
Change-Id: I47e748f18abf947a769e09df3814bd2a3443b11b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297894
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78043}
2021-11-23 15:27:19 +00:00
Omer Katz
d315657ef5 heap: Mark EmbedderHeapTracer::GarbageCollectionForTesting as deprecated
Bug: v8:12407
Change-Id: Iedf6154796423267fdb32125a408e580bb3c205b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295349
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78030}
2021-11-22 23:15:28 +00:00
Dominik Inführ
2c88cec4cf Reland "[heap] Support multiple clients in shared GC"
This is a reland of 90a9d6cb13

The original CL got reverted because of two different issues:

* The DCHECK failure on AllowGarbageCollection::IsAllowed() got fixed
  in https://crrev.com/c/3289625.
* The crash with the incremental marking job were because of a nested
  GC started from a SafepointScope. This CL adds IgnoreLocalGCRequests
  scopes to SafepointScopes in src/heap.

In addition this CL prevents shared GCs during isolate deserialization
by locking the clients_mutex_ until the isolate is fully deserialized.
The original GC used a DisallowSafepoints scope to prevent shared GCs
from interrupting isolate deserialization.

Original change's description:
> [heap] Support multiple clients in shared GC
>
> Add support for safepointing multiple isolates as described in the
> design doc (link is below). A safepoint across multiple isolates is
> considered a global safepoint to distinguish it from regular safepoints.
>
> The basic idea behind the implementation is that we reach a
> safepoint for each client. What's new is that now also main threads
> need to participate in the safepointing protocol and need to give up
> control in time. The slow paths of Park(), Unpark() and Safepoint() on
> the main thread need to be adjusted for this reason as well.
>
> This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
> IsolateSafepoint and IsolateSafepointScope.
>
> This CL adds the type IgnoreLocalGCRequests, it is used to prevent
> Park() and Unpark() from honoring the request from background threads
> to perform a local GC. This is used heap-internally to not have GCs
> (or even nested GCs) in certain locations. E.g. when initiating a
> safepoint to perform a GC we don't want a "recursive" GC to occur.
>
> Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
>
> Bug: v8:11708
> Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77812}

Bug: v8:11708, v8:12375, v8:12377
Change-Id: I9d1af6fbc06a3a8b6f216ec5e9027665ad071809
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283067
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78013}
2021-11-22 08:40:57 +00:00
Ng Zhi An
f47eec071e [ic] Fix -Wshadow by making InlineCacheState an enum class
Bug: v8:12244,v8:12245
Change-Id: Ie2b1801d7535e142774a1d912b992a203b1b8ecc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284005
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78000}
2021-11-19 18:52:15 +00:00
Jakob Gruber
f6f829b49f [compiler,code] Refactor code dependencies
Prior to this CL we regularly generated high counts of code
dependencies, and installation was not the most efficient.

This CL 1) implements early dependency deduplication and
2) simplifies the way dependencies are persisted on the heap
through DependentCode.

Re 1): we dedupe twice, once based on the CompilationDependency
contents, and again once we know the final target object.

Re 2): Instead of a linked list of weak fixed arrays per
dependency group, store deps in a flat array together with a
bitset of their dependency groups.

See also:
https://docs.google.com/document/d/1B34S1s3Iv6hbquZ93RugD0b-ZKfHEptJ8Fk_YyOvjDk/edit

Bug: v8:12195,v8:12397
Change-Id: I9ab47f6d87b10558194b5de30a36b1122f7e362a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283074
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77969}
2021-11-18 13:22:57 +00:00
Victor Gomes
521b7a8398 [test] Fix StressJS
CodePageCollectionMemoryModificationScope was wrongly added to the test.
On M1, the code object is unprotected to RW and crash when running it later.

Bug: v8:12386, v8:12396
Change-Id: I1af3dabaa9b66d1f50033f298107949fcb35c3d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289155
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77947}
2021-11-17 13:31:02 +00:00
Igor Sheludko
579c3b0ff7 [heap][cleanup] Rename kWordAligned to kTaggedAligned
Also introduce USE_ALLOCATION_ALIGNMENT_BOOL constant which is true
only for those configurations that require aligned allocations and
use it for statically falling back to unaligned allocations on those
configurations that do not require aligned allocations.

This is a prerequisite for introducing the real kWordAligned mode for
kSystemPointerSize aligned allocations.

Bug: v8:8875
Change-Id: I155d12435f344324bc1bf19da88ee823c8f2ca6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283064
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77918}
2021-11-16 09:14:24 +00:00
Victor Gomes
42036e7e7e [heap] Adds DCHECK in UnprotectAndRegisterMemoryChunk
UnprotectAndRegisterMemoryChunk should only be called if we have
CodePageCollectionMemoryModificationScope or
CodeSpaceMemoryModificationScope open.

This also fixes cctests that create code objects without a
code modification scope.

Bug: v8:12054
Change-Id: Id931f1f8120050b2bb76ef3d5701b9a32e52ff37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277882
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77873}
2021-11-12 16:27:56 +00:00
Dominik Inführ
2f98fb28d6 Revert "[heap] Support multiple clients in shared GC"
This reverts commit 90a9d6cb13.

Reason for revert: Seems to make some test to fail flakily. Revert for now until this is fixed.

Original change's description:
> [heap] Support multiple clients in shared GC
>
> Add support for safepointing multiple isolates as described in the
> design doc (link is below). A safepoint across multiple isolates is
> considered a global safepoint to distinguish it from regular safepoints.
>
> The basic idea behind the implementation is that we reach a
> safepoint for each client. What's new is that now also main threads
> need to participate in the safepointing protocol and need to give up
> control in time. The slow paths of Park(), Unpark() and Safepoint() on
> the main thread need to be adjusted for this reason as well.
>
> This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
> IsolateSafepoint and IsolateSafepointScope.
>
> This CL adds the type IgnoreLocalGCRequests, it is used to prevent
> Park() and Unpark() from honoring the request from background threads
> to perform a local GC. This is used heap-internally to not have GCs
> (or even nested GCs) in certain locations. E.g. when initiating a
> safepoint to perform a GC we don't want a "recursive" GC to occur.
>
> Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
>
> Bug: v8:11708
> Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77812}

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:11708
Change-Id: I85fbf896c59492fc571b3bfaa7f9e3ea8a883260
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275552
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77845}
2021-11-11 12:38:37 +00:00
Dominik Inführ
c26cdb40b2 [test] Skip test with FLAG_single_generation
Test needs young generation to work properly.

Bug: v8:12380
Change-Id: I5dca5bd6be10371ee9aabf263c4f8491917b9803
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275556
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77844}
2021-11-11 12:17:28 +00:00
Michael Lippautz
c88140fed6 heap: Rename compaction flags
Rename flags to align them with other flags that are named in an
enabled way and drop the "never" prefix.

Drive-by: Refactor compaction entry point.

Bug: v8:12251
Change-Id: If2b189152f3cd22038b87fe3cc2ba0db4953ae23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270534
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77813}
2021-11-10 09:01:59 +00:00
Dominik Inführ
90a9d6cb13 [heap] Support multiple clients in shared GC
Add support for safepointing multiple isolates as described in the
design doc (link is below). A safepoint across multiple isolates is
considered a global safepoint to distinguish it from regular safepoints.

The basic idea behind the implementation is that we reach a
safepoint for each client. What's new is that now also main threads
need to participate in the safepointing protocol and need to give up
control in time. The slow paths of Park(), Unpark() and Safepoint() on
the main thread need to be adjusted for this reason as well.

This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
IsolateSafepoint and IsolateSafepointScope.

This CL adds the type IgnoreLocalGCRequests, it is used to prevent
Park() and Unpark() from honoring the request from background threads
to perform a local GC. This is used heap-internally to not have GCs
(or even nested GCs) in certain locations. E.g. when initiating a
safepoint to perform a GC we don't want a "recursive" GC to occur.

Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing

Bug: v8:11708
Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77812}
2021-11-10 08:40:09 +00:00
Dominik Inführ
ef1640b8b1 [heap] Remove flag always_promote_young_mc
This flag is now enabled by default for quite some time in production.
In addition that flag was already defined readonly and couldn't be
disabled, so let's remove this flag for good.

Bug: v8:10064
Change-Id: I0e71eee9d25960a96324d56c8f0191fe678dc6e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268907
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77806}
2021-11-09 19:37:39 +00:00
Victor Gomes
5bb577eaf3 [heap] Forces CodeSpaceMemoryModificationScope only in safepoints
CodeSpaceMemoryModificationScope should only be used by the main
thread and during a safepoint. This adds a check in
CodeSpaceMemoryModificationScope.

The reason for this is that CodeSpaceMemoryModificationScope is not
thread-safe. It assumes that no other thread is modifying code space
(either by setting memory permission or adding a new page).

This CL also replaces CodeSpaceMemoryModificationScope to
CodePageCollectionMemoryModificationScope in a few occurrences, where
the former is not needed. This should not hurt performance.

Bug: v8:12054
Change-Id: I2675e667782c6ad8410877a4e64374899066bcd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3263890
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77732}
2021-11-05 14:34:41 +00:00
Leszek Swirski
eaaaed9735 [cleanup] Remove compiler.h from js-function-inl.h
Change-Id: I17104eba48919c4608d6ab7e91cb09601a2f71d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250636
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77599}
2021-10-28 17:20:30 +00:00
Michael Lippautz
e5a509049e api: Provide write barrier in TracedReferenceBase
TracedReferenceBase use (traced) global handles to implement the
referencs. Provide a write barrier in the corresponding handle
methods. Doing so
- avoids bugs by having embedders taking care of write barrier
  management.
- speeds up the barrier as it is better integrated in the handle
  methods.

Drive-by: We don't need write barriers on initializating stores.

Bug: v8:12165
Change-Id: Ie49cc3783aeed576fd46c957c473c61362fefbf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247039
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77593}
2021-10-28 12:00:32 +00:00
Ng Zhi An
9611ceafda [cctest] Fix -Wshadow warnings in cctest/heap
No functionality change expected.

Most scopes are renamed new_scope or new_handle_scope. For some test
cases the outer scope is renamed to outer_scope since there are
multiple inner scopes.

Bug: v8:12244,v8:12245
Change-Id: I85953617e54f2140fa88c593eb7c186b570fdd04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3227266
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77442}
2021-10-18 16:34:30 +00:00
Igor Sheludko
59c381077e [ext-code-space] Introduce RelocInfo::target_object(PtrComprCageBase)
... as a result of merging RelocInfo::target_object() with
RelocInfo::target_object_no_host(PtrComprCageBase),
where the cage base is used for accessing compressed embedded pointers.

There are two reasons for this change:
1) the parameterless version used to compute the cage base value from
   the host Code object, however, when external code space is enabled
   such a base value will not work for non-Code objects, since they
   require different cage base for decompressing,
2) when external code space is enabled, there must be no need to embed
   compressed Code objects at all because CodeDataContainers must be
   used instead.

In addition this CL introduces DCHECKs to enforce (2).

Bug: v8:11880
Change-Id: I5b504f91dea87c2bcaa1165d2dbfaada70cba7be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211998
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77361}
2021-10-12 15:43:34 +00:00
Shu-yu Guo
388a80bab7 [snapshots] Add a new snapshot for shared heap objects
This CL adds a new snapshot to hold objects that are in the shared heap
or may need to be in the shared heap depending on runtime flags.
Currently this is to support --shared-string-table, which puts all
in-place-internalizable strings, internalized strings, and the
string table into the shared heap.

The shared heap snapshot is never deserialized into client Isolates.
This means when V8 is started without a shared Isolate, the shared heap
snapshot is deserialized into all Isolates.

Bug: v8:12007
Change-Id: I7eeab73080cda2e8250a5a49747f25b2440a349d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3173905
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77309}
2021-10-08 23:24:58 +00:00
Shu-yu Guo
98d7bbb435 [strings] Add --shared-string-table and support in d8
This CL reorders the initialization scheme for shared and client
Isolates such that clients attach to the shared Isolate before
setting up the Heap. This is to support sharing the string table.

Bug: v8:12007
Change-Id: Icb0e40cc5ed84d516c8073a70d0f769f517044c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3039264
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77307}
2021-10-08 22:40:28 +00:00
Samuel Groß
18c37d3258 Add PageInitializationMode enum for the BoundedPageAllocator
Currently, when compiling with V8_VIRTUAL_MEMORY_CAGE enabled, the
behavior of the BoundedPageAllocator changes from simply making freed
pages inaccessible to decommitting them, which guarantees that they will
be zero-initialized after the next allocation. As this seems to cause
some performance regressions on Mac, this CL introduces a new enum that
specifies how the allocator should behave:
kAllocatedPagesMustBeZeroInitialized causes the pages to be decommitted
during FreePages() and ReleasePages() and thus guarantees
zero-initialization during AllocPages().
kAllocatedPagesCanBeUninitialized only causes the pages to be made
inaccessible, and so does not generally guarantee zero-initialization
for AllocPages().

Finally, this CL also removes some dead code in allocation.cc.

Bug: chromium:1257089
Change-Id: I53fa52c8913df869bee2b536efe252780d1ad893
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3208812
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77285}
2021-10-07 12:55:39 +00:00
Marja Hölttä
db50b49128 [csa, torque, cleanup] Rename CSA_ASSERT to CSA_DCHECK
It's confusing that we have CSA_CHECK and CSA_ASSERT and it's not
clear from the names that the former works in release mode and the
latter only in debug mode.

Renaming CSA_ASSERT to CSA_DCHECK makes it clear what it does. So now
we have CSA_CHECK and CSA_DCHECK and they're not confusing.

This also renames assert() in Torque to dcheck().

Bug: v8:12244
Change-Id: I6f25d431ebc6eec7ebe326b6b8ad3a0ac5e9a108
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190104
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77160}
2021-09-30 08:41:23 +00:00
Igor Sheludko
8efa70f076 [ext-code-space] Introduce managed-inl.h and global-handles-inl.h
... and move methods that use XXX::cast() there.
This will untangle the include cycle that'll happen in a follow-up CLs.

Bug: v8:11880
Change-Id: Iba46bc9b0e0df9530197f57d0469456eb9006e66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3164456
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76932}
2021-09-20 10:29:29 +00:00
Dominik Inführ
b8146576d6 Reland "[test] Avoid disabling of RCS during runtime"
This is a reland of 11045926ca

The first version of this CL uncovered a TSAN failure when not disabling
RCS anymore. The problem was that a background thread was still updating
RCS counters, while the main thread already dumped those values during
tear down. This CL fixes this by dumping counters only after all
background threads are stopped.

Original change's description:
> [test] Avoid disabling of RCS during runtime
>
> Test was flaky since disabling of RCS at runtime is unsafe. Some code
> (e.g. TRACE_GC) is run only in case RCS is enabled and such code paths
> might also DCHECK that RCS is enabled.
> A background thread (sweeping in this case) could've already
> entered such a code path right before RCS is disabled. In this case the
> guard at the entry still saw that RCS is enabled but subsequent DCHECKs
> that ensure that RCS is enabled might fail.
>
> We could fix this by completing the sweeper tasks before disabling RCS
> but there might be other similar tasks which might be run at that point
> in the future (e.g. memory unmapper).
>
> Disabling the flag doesn't even seem to be needed for the initial
> regression test, so it seems simpler to just not disable RCS anymore.
>
> Bug: v8:12026
> Change-Id: I878f7dd9a7a4abb6a501f7a7651a1240ef2082a6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162043
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76845}

Bug: v8:12026, v8:12234
Change-Id: I5cb577051d188d17b02ca7da79a3f1d9aa646cae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162050
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76859}
2021-09-16 06:05:51 +00:00
Dominik Inführ
0feba98a5c Revert "[test] Avoid disabling of RCS during runtime"
This reverts commit 11045926ca.

Reason for revert: Uncovered TSAN failure

Original change's description:
> [test] Avoid disabling of RCS during runtime
>
> Test was flaky since disabling of RCS at runtime is unsafe. Some code
> (e.g. TRACE_GC) is run only in case RCS is enabled and such code paths
> might also DCHECK that RCS is enabled.
> A background thread (sweeping in this case) could've already
> entered such a code path right before RCS is disabled. In this case the
> guard at the entry still saw that RCS is enabled but subsequent DCHECKs
> that ensure that RCS is enabled might fail.
>
> We could fix this by completing the sweeper tasks before disabling RCS
> but there might be other similar tasks which might be run at that point
> in the future (e.g. memory unmapper).
>
> Disabling the flag doesn't even seem to be needed for the initial
> regression test, so it seems simpler to just not disable RCS anymore.
>
> Bug: v8:12026
> Change-Id: I878f7dd9a7a4abb6a501f7a7651a1240ef2082a6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162043
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76845}

Bug: v8:12026
Change-Id: I154817fc5ddeab68c69c745d08f3d77c48896dc4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162049
Auto-Submit: Dominik Inführ <dinfuehr@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/main@{#76848}
2021-09-15 15:02:20 +00:00
Dominik Inführ
11045926ca [test] Avoid disabling of RCS during runtime
Test was flaky since disabling of RCS at runtime is unsafe. Some code
(e.g. TRACE_GC) is run only in case RCS is enabled and such code paths
might also DCHECK that RCS is enabled.
A background thread (sweeping in this case) could've already
entered such a code path right before RCS is disabled. In this case the
guard at the entry still saw that RCS is enabled but subsequent DCHECKs
that ensure that RCS is enabled might fail.

We could fix this by completing the sweeper tasks before disabling RCS
but there might be other similar tasks which might be run at that point
in the future (e.g. memory unmapper).

Disabling the flag doesn't even seem to be needed for the initial
regression test, so it seems simpler to just not disable RCS anymore.

Bug: v8:12026
Change-Id: I878f7dd9a7a4abb6a501f7a7651a1240ef2082a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162043
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76845}
2021-09-15 13:49:08 +00:00
Michael Lippautz
210987a552 heap: ArrayBufferSweeper refactoring
The refactoring is triggered by https://crrev.com/c/3121905 where we
noticed that a bunch of tricky counter paths could be simplified,
making reasoning about corectness easier.

In this CL:
1. Use uniqe_ptr instead of Optional to allow moving SweepingJob away
   from the header file.
2. sweeping_in_progress_ is replaced with simply checking for a job.
3. freed_bytes_ are moved to the job and the dependency is reversed,
   avoiding the inside-out (Job->Sweeper) dependency completely.
4. Merge() and counter updates are merged into a Finalize() method.
5. FinishIfDone() allows for conditional finization.
6. young_bytes_ and old_bytes_ are removed as they were always updated
   when the corresponding bytes in the ArrayBufferList was updated.

Change-Id: I56e5b04087166ce03d3a9195ac48359122a84c73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3124776
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76795}
2021-09-13 11:49:02 +00:00
Dan Elphick
ec06bb6ce5 Reland "[include] Split out v8.h"
This is a reland of d1b27019d3

Fixes include:
Adding missing file to bazel build
Forward-declaring classing before friend-classing them to fix win/gcc
Add missing v8-isolate.h include for vtune builds

Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}

Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
Bug: v8:11965
Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76460}
2021-08-24 13:08:55 +00:00
Maya Lekova
438989d6c1 Revert "[codegen] Assert that deserialized SFIs have correct origins"
This reverts commit 2660997331.

Reason for revert: Breaks code_serializer tests - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/36427/overview

Original change's description:
> [codegen] Assert that deserialized SFIs have correct origins
>
> Re-use the same check we already have in place for the
> compilation cache for when we use CodeSerializer::Deserialize.
>
> - Move HasOrigin to SharedFunctionInfo::HasMatchingOrigin
> - HasMatchingOrigin no longer allocates
> - Pass ScriptDetails in more places
>
> Bug: v8:10284
> Change-Id: I6e074bd1e7db9a35fdf7123d04a65841d9813e02
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3090968
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76451}

Bug: v8:10284
Change-Id: I234fcf031001819b05dbcdd421f235f71e9805b2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3114143
Auto-Submit: Maya Lekova <mslekova@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/main@{#76456}
2021-08-24 11:48:22 +00:00
Camillo Bruni
2660997331 [codegen] Assert that deserialized SFIs have correct origins
Re-use the same check we already have in place for the
compilation cache for when we use CodeSerializer::Deserialize.

- Move HasOrigin to SharedFunctionInfo::HasMatchingOrigin
- HasMatchingOrigin no longer allocates
- Pass ScriptDetails in more places

Bug: v8:10284
Change-Id: I6e074bd1e7db9a35fdf7123d04a65841d9813e02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3090968
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76451}
2021-08-24 10:35:45 +00:00
Dan Elphick
44fe02ced6 Revert "[include] Split out v8.h"
This reverts commit d1b27019d3.

Reason for revert: Broke vtune build, tsan build and possibly others

Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}

Bug: v8:11965
Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76428}
2021-08-23 11:54:09 +00:00
Dan Elphick
d1b27019d3 [include] Split out v8.h
This moves every single class/function out of include/v8.h into a
separate header in include/, which v8.h then includes so that
externally nothing appears to have changed.

Every include of v8.h from inside v8 has been changed to a more
fine-grained include.

Previously inline functions defined at the bottom of v8.h would call
private non-inline functions in the V8 class. Since that class is now
in v8-initialization.h and is rarely included (as that would create
dependency cycles), this is not possible and so those methods have been
moved out of the V8 class into the namespace v8::api_internal.

None of the previous files in include/ now #include v8.h, which means
if embedders were relying on this transitive dependency then it will
give compile failures.

v8-inspector.h does depend on v8-scripts.h for the time being to ensure
that Chrome continue to compile but that change will be reverted once
those transitive #includes in chrome are changed to include it directly.

Full design:
https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing

Bug: v8:11965
Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76424}
2021-08-23 09:35:06 +00:00
Michael Lippautz
847f6d9aba heap: Fix TSAN race when setting a flag after page initialization
HAS_PROGRESS_BAR is set after page initialization at which point all
flags are assumed to be immutable while a GC is running.

Separating out the progress bar from flags allows setting it lazily at
allocation time.

Bug: v8:11915
Change-Id: I48a877e0e80d583d7a0fadef2546fc70417806e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3085268
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76382}
2021-08-19 10:28:57 +00:00
Samuel Groß
8581adaee6 Introduce v8_enable_virtual_memory_cage
When this is enabled, v8 reserves a large region of virtual address
space during initialization, at the start of which it will place its 4GB
pointer compression cage. The remainder of the cage is used to store
ArrayBuffer backing stores and WASM memory buffers. This will later
allow referencing these buffers from inside V8 through offsets from the
cage base rather than through raw pointers.

Bug: chromium:1218005
Change-Id: I300094b07f64985217104b14c320cc019f8438af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3010195
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@google.com>
Cr-Commit-Position: refs/heads/master@{#76234}
2021-08-11 16:13:42 +00:00
Camillo Bruni
06a63fe129 [codegen] Use ScriptDetails as parameter in CompilationCacheScript
- Add separate script-details.h file
- Follow-up CL will add support for precise caching with custom
  host options

Bug: v8:10284
Change-Id: I37be2079434ba7029c160ca811c7ce00a147f539
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069151
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76077}
2021-08-04 08:24:22 +00:00
Peter Kasting
28661339c7 Fix an instance of -Wunused-but-set-variable.
Bug: chromium:1203071
Change-Id: I09724552731594ddf18358d29cdc243cb696652d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3053617
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75929}
2021-07-26 20:52:03 +00:00
Camillo Bruni
c573dcc8f8 [isolate] Minor cleanup for exceptions
* Avoid accessing thread_local_top directly and use getters:
  - scheduled_exception
  - pending_exception
  - pending_message

* Rename pending_message_obj to pending_message

Bug: chromium:1014421
Change-Id: I080b7d5919e180a943776c79ee9321235d58d3c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3010278
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75864}
2021-07-22 15:06:15 +00:00