Implementation copied from d8. Gated behind a build-time flag.
Can be useful for debugging issues.

Change-Id: I444d625242b1fb8fe9139472a06cb1a90269401a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2906233Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74767}

Change-Id: I795d45a02f49e3a0cc62ce5d87b75a1af7b2dcc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917913
Commit-Queue: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Auto-Submit: Junliang Yan <junyan@redhat.com>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74766}

Change-Id: Idb38b9f97b5a507abd6f65f0d6c126255069f979
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917914Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74765}

Fixes an issue with tests mjsunit/compiler/call-with-arraylike-or-spread*
that fail when run with the fuzzer.

Bug: v8:11821
Change-Id: I6b75c065397d66062a7f552198ca92d151d89a4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917814Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74764}

For mprotect-based write protection of WebAssembly code memory, we open
{NativeModuleModificationScope}s each time a thread needs write-access
to the code space. While fine-grained switching is good for security
(the permission should only be granted for as short as possible,
especially since it is process-wide), this can degrade performance
considerably for two reasons (we measured up to 10x slower Liftoff
compilation time cf. having no write protection):

1. Switching permissions with mprotect() (and likely with similar
functions on non-POSIX platforms) is just inherently expensive due to
the syscall, modifying page tables, and potentially subsequent TLB
flushes. For a simple benchmark (compiling Unity with --liftoff-only)
--wasm-write-protect-code-memory increases the number of mprotect
syscalls from ~2.6-2.8k to 6-8k (!).

2. Modifying the permissions in {SetWritable()} is synchronized
across threads via the {NativeModule::allocator_mutex_}. With many fine-
grained permission switching requests, lock contention on this mutex
incurs a very high number of futex syscalls (measured on Linux only,
but the problem is likely a general one). For the same simple benchmark
as above (compiling Unity), --wasm-write-protect-code-memory increases
the number of futex syscalls from ~1k to 20-40k (!).

Both problems are fixed in the CL here, following this simple recipe
(in case we get more of these issues in the future):
1. Identify the hot syscall either via sampling-based profiling with
`sudo perf record -g -F10000 d8 ...` (needs sudo for kernel stacks) and
then looking into the record or a flamegraph, or with event-based
profiling with `sudo perf stat -g -e 'syscalls:sys_enter*' d8 ...`.
In particular, if {NativeModuleModificationScope}s are repeatedly
opened (behind a function) in a loop, this can be a problem.
2. Add a scope object outside of the loop, potentially to a function
upwards in the call hierarchy of the hot loop/function.
3. Remove the scope object in the innermost function/hot loop.
4. Check all callers of the hot function (which now no longer has a
scope object), whether additional scopes need to be added there for
correctness.

The following two offenders were especially visible in the profile:
- Most of the mprotect calls were coming from {PatchJumpTablesLocked}.
Pulled the scope object up into {PublishCode}.
- Most of the lock contention was caused by {AddCodeWithCodeSpace}.
There already was a scope object up the call chain in {AddCompiledCode}.
- Fixed scope inside the loop in {FreeCode} for good measure as well.

R=clemensb@chromium.org
CC=​​​jkummerow@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng

Bug: v8:11663, chromium:932033
Change-Id: I89e4a1f0998f06e4d4b5e360e0bf81836d4240f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912786
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74763}

Bug: v8:11804
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: I81ba1408fb2701450a82c4abc29d2422746af78e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917041
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74762}

Change-Id: I6d2469cdaee5a2c4bf5ce72f8a83a458d4135cc4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917573
Auto-Submit: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74761}

This patch constantize the table size, both for primary and secondary tables, whenever the table size
is known to never change.

By default WebAssebly tables can be grown indefinitely, but producers can specify a maximal limit.
In particular, producers can specify that the initial size of the table also correspond to the
maximum size, in which case the table cannot be grown and the size is constant.

This is a common case, for example when generating WebAssembly from a C++ codebase the list
of indirectly called function does not need, in general, to change at runtime.

Change-Id: I7f6bab60841ee8eb8bdfd996c34513f69b74d5d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912586Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74760}

https://chromium.googlesource.com/external/github.com/tc39/test262/+log/6d353a..d454b8

Bug: v8:7834
Change-Id: I74f4e48b036385a77679b39085125e7a60c90047
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912917Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74759}

Note: OutOfLineRecordWrite on arm/arm64 only takes "object" and "value"
as arguments. The currently can be the same and thus we don't add any
additional DHCECKs there.

Change-Id: I757d1f3ba9c0d0c5994ecedf26728454e32f41a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916813
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74758}

This reland is a manual revert of the previous revert
(commit 815bab9f). Manual
due to merge conflicts. No other changes.

Original change's description:
> [compiler] Remove one ObjectRef constructor
>
> Remove the handle-taking ObjectRef constructor in favor of
> (Try)MakeRef as bottleneck.
>
> Bug: v8:7790
> Change-Id: I3cc3a1dcef4bac53a91c573d1a532332b88c6eb4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2883664
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74593}

Bug: v8:7790
Tbr: jgruber@chromium.org
Change-Id: Iafc68f68df06ca9f404427d272b663c218d6550a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917039Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74757}

Switches internals of BasePage and some getters to references that are
guaranteed non-null.

Bug: v8:11822
Change-Id: I484c4451720dc7e04f8b89dbe4fef03a3eaf817e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917038Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74756}

The spec uses the CreateDataProperty abstract operation to add
properties to the result object of Object.fromEntries.

Confusingly, the FastCreateDataProperty Torque macro is special-cased
for adding array element properties instead of generic keyed properties.
The slow path for FastCreateDataProperty goes to runtime, which was
being hit everytime in Object.fromEntries since the result object is not
an array.

This CL switches to using StorePropertyInLiteral instead, which
corresponds to the CreateDataProperty spec operation, and also has fast
paths that stay in CSA.

Bug: v8:11814
Change-Id: I72a6809bde556f0888806307816e200bd47edf8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2915755Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74755}

After https://crrev.com/c/2905605, input type might
also be a register in which case different number of instructions
get emitted. The number also changes if constant pool is
disabled.

Port: 54d84cf3

Change-Id: I9a7adb02de55caebaad552c1e15440c97b4384b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2914055
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74754}

This was missing for transitioning stores.

Bug: chromium:1209558
Change-Id: Ib75d919ef748cffd12f0add09ac2718f434eb684
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916815Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74753}

ResetLinearAllocationBuffer() must be called as part of the marking
phase as it may free the current LAB which decreases live bytes which
previously could have caused an underflow.

Bug: chromium:1056170
Change-Id: I8a641fe340f5faf0dfad32cda84f796d0537134b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917034
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74752}

This is a reland of 50cbeca9

Relanding as-is, only rebase-related changes. Reason for reland: was
speculatively reverted.

Original change's description:
> [codegen] Use builtin calls for TSANRelaxedStore
>
> Instead of calling the C function directly from codegen, we call a
> builtin that calls the C function. This is done to encapsulate the
> push/pop registers in the code in the builtin.
>
> Bug: v8:7790, v8:11600
> Change-Id: I4c77a80803d4eb44526b716901afe0e8ccbe077d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2892663
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74599}

Bug: v8:7790, v8:11600
Change-Id: Ide78ca82f38ee84bb7d24f5da2b4e8a8bd26621a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2914877Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74751}

The test performs manual GC with custom GC flags.

Bug: v8:11820
Change-Id: I717411b3c32e468066060e8c4cb8b794a2fe219f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917035
Auto-Submit: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74750}

This is a reland of 83c11a30

Original change's description:
> [test] Re-enable test-heap/OutOfMemory* test
>
> The underlying issue was fixed in
> https://chromium-review.googlesource.com/c/v8/v8/+/2505724
>
> Bug: v8:7605,v8:8296
> Change-Id: I4a35fd4b73f86934a9d1339655433e2d4c26bd53
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912890
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74729}

Bug: v8:7605
Bug: v8:8296
Change-Id: I734ad0424d8432d01bf1d1701a232f4535b32569
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916817
Auto-Submit: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74749}

HeapRegistry requires a valid PageBackend for querying containment.
Reorder fields to guarantee that a backend is indeed available.

Bug: chromium:1056170
Change-Id: I32c0251d67ff99cd3609946154526f648c16c617
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916818
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74748}

This tests the hypothesis that the current timeout problems are on
Bionic bots only.

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

Enable more complex tooltips with clickable links and references.

- Use short filename for Script.name if they are unique
- Use shared App.isClickable method
- Remove various toStringLong methods
- Rename CodeLogEntry.disassemble to .code
- Add DOM.button helper

Bug: v8:10644
Change-Id: I5d46ffd560b37278dc46b8347cb9ff0a7fdfa2ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916373Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74746}

Change-Id: I6e8f1023c761b94f6e2f6dc985a10f58056667d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916814
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74745}

This is a first step towards supporting unwrapped WasmObject objects on
JavaScript side.

In addition this CL
1) introduces Representation::WasmValue which is used for all WasmObject
   fields exposed to JavaScript side.
2) adds creation of meaningful DescriptorArrays for WasmObject's Maps.

Bug: v8:11804
Change-Id: I4afcd39da5cb77b659943da54a2ca34d13bcc9bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912776
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74744}

Bug: chromium:1192162
Change-Id: Ida55f1b9f8543177851a2d037b576fc33c44b807
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912581Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74743}

There are two different limits for the maximum memory size in
WebAssembly:
1) A 4GB limit which is the same on all platforms, and is observable for
JS programs. It is used to limit the allowed declared maximum size of a
wasm memory.
2) A potentially lower limit (2GB on 32-bit systems, 4GB otherwise)
which can be further limited using a command-line flag. This limit is
used whenever actually allocating or growing a wasm memory. This limit
is not directly observable, but we make sure that no wasm memory will
ever be bigger than this limit.

The second limit is the one we should check against when allocating or
growing memory, while the first limit should be used when validating
a module (or the parameters for WebAssembly.Memory). The compiler can
rely on no memory being bigger than the second limit, which again is
never bigger than the first limit.

This CL adds some more documentation to the two limits, and cleans up
all usages.
This also makes {kPlatformMaxPages} and {kMaxMemoryPagesAtRuntime}
obsolete.

R=jkummerow@chromium.org

Bug: chromium:1207263
Change-Id: I43541aafd3f497d1c368bd9400e9bc667bdfd3d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910787
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74742}

The previous fix force --single-threaded-gc, but that has no effect
without reapplying flag implication as done in this fix.

Bug: v8:11413
Change-Id: Iecb2d74c7eb8322638dcc843723c560dcbb7bf50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912892
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74741}

Bug: chromium:1197053, chromium:324812
Change-Id: I2cccabf838e3a3acbb3adfed33aa59400ec91b11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2821547Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74740}

This is a reland of 5ef4e14f

The previous CL caused flaky test failures with some concurrent
allocation tests. The reason for this was that the main thread's state
and collection_requested_ can't be updated in an atomic operation
anymore.

Any thread will now invoke RequestGC() first. Then it will wait in
AwaitCollectionBackground() when the main thread was running. Both
methods can and will be invoked more than once.

The new flag block_for_collection_ is used to decide whether a thread
needs wait for the GC. collection_requested_ can't be used for that
purpose because that flag is also true when the main thread is parked.

Original change's description:
> [heap] Replace usages of CollectionRequested with SafepointRequested
>
> CollectionRequested was used exclusively on the main thread when a
> background thread requested a GC. The main thread never used
> SafepointRequested at any time. Now with the shared GC we might need to
> stop multiple isolates in a safepoint in the future. In such a situation
> we would need to use SafepointRequested also on the main thread.
>
> This CL prepares V8 for this situation by using SafepointRequested
> instead of CollectionRequested and friends on the main thread. The slow
> path of Safepoint(), Park() and Unpark() will check in the future
> whether the main thread needs to halt for a shared GC or needs to
> perform a local GC. At the moment, simply performing the local GC is
> still enough.
>
> Bug: v8:11708
> Change-Id: I819b6f7db8251074a4adf8b554e0a1393c76f7da
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891834
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74673}

Bug: v8:11708
Change-Id: Ibe245cd1822310123b3af2026872fd9927ee410e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912576
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74739}

This reverts commit 83c11a30.

Reason for revert: Test is consistently timing out on TSan: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN/36827/overview

Original change's description:
> [test] Re-enable test-heap/OutOfMemory* test
>
> The underlying issue was fixed in
> https://chromium-review.googlesource.com/c/v8/v8/+/2505724
>
> Bug: v8:7605,v8:8296
> Change-Id: I4a35fd4b73f86934a9d1339655433e2d4c26bd53
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912890
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74729}

Bug: v8:7605
Bug: v8:8296
Change-Id: Ie1dab9bef269ac980dcd2663c76f80713a68d9d6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910631
Auto-Submit: Clemens Backes <clemensb@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@{#74738}

This is a reland of 0a661a9a without
changes (dependency has relanded).

Original change's description:
> Revert "[compiler] Temporarily change ContextRef back to kSerialized"
>
> This reverts commit 445f0f74.
>
> Reason for revert: TryMakeRef is again ready for this.
>
> Original change's description:
> > [compiler] Temporarily change ContextRef back to kSerialized
> >
> > This can be reverted once TryMakeRef checks the heap predicate.
> > I'm not reverting the previous CL because newer changes already depend
> > on it.
> >
> > Tbr: jgruber@chromium.org
> > Bug: v8:11765, v8:7790
> > Change-Id: Iacc6a78a70fe6f40c9421258889c2175fb400b04
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891579
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Commit-Queue: Georg Neis <neis@chromium.org>
> > Auto-Submit: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#74531}
>
> Bug: v8:11765
> Bug: v8:7790
> Change-Id: I0b38791255182f1f8d0a5cf79f18d86568172487
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897101
> Commit-Queue: Georg Neis <neis@chromium.org>
> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Auto-Submit: Georg Neis <neis@chromium.org>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74591}

Bug: v8:11765
Bug: v8:7790
Change-Id: I2fc5e0f3b13586479b3608770411bab4cb3d0591
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904219Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74737}

Bug: v8:3716
Change-Id: Id884bf17dd4173546012aabe24263dac6d68b620
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910782
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74736}

This is a reland of 1186fc50

This reland fixes NewSpaceAllocationTopAddress() and
NewSpaceAllocationLimitAddress() by returning nullptr if no new space
is available. This is okay since those are never used later on.

We can't make this a build-time flag because we may only want to disable
the new space for the shared heap.

Original change's description:
> [heap] Disable the young generation in shared heaps
>
> A shared heap will not have a young generation in the beginning.
>
> Bug: v8:11708
> Change-Id: I947ddb91a23a72a8cee3aa3e554723dda8146011
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891569
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74697}

Bug: v8:11708
Change-Id: I254b919f7076ce624d15c924e63cbde5eb4df749
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912731Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74735}

Change-Id: I29b3a805a6031bf874e8b7e0775f5725b6180fca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2914879Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74734}

Trimming is required before the Typer phase to ensure that all nodes
that might be reached via use links have been typed.

Add this phase back on the (background thread) OptimizeGraph
step instead of the (main-thread) CreateGraph phase since there
is no need to do it on the main thread.

BUG=chromium:1212244

Change-Id: I136aadb62d623c8f1898e4e9c0441266d5690be6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912709Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74733}

The options/cause property is optional, it should not increase its length.

Bug: chromium:1192162
Change-Id: Id3bcc774232320d503d327a95f5e152d0e980e0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912732
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74732}

Bug: v8:3742
Change-Id: Ib63b7bacac07456dc1d7bf496b67980a34be306c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912883
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74731}

R=victorgomes@chromium.org

Change-Id: I2f6ba1d0b127567859c57dd42b73d7e4e0a8d29e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912728Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74730}

The underlying issue was fixed in
https://chromium-review.googlesource.com/c/v8/v8/+/2505724

Bug: v8:7605,v8:8296
Change-Id: I4a35fd4b73f86934a9d1339655433e2d4c26bd53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912890Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74729}

The test has a loop that allocates large objects until it gets an
allocation failure. The test then asserts that the subsequent allocation
should also fail. That however does not necessarily hold because the
previously allocated objects may be collected to free up the space.

This change creates a handle for each allocated object. It also
restricts the size of the heap to 20MB to reduce memory consumption.

Bug: v8:11172
Change-Id: Ic3dc1a0f5f235b0313bab2071546b59a77bd55e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912884
Auto-Submit: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74728}