This reverts commit 137bfe47c9.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/13072
Original change's description:
> [arm64] Protect return addresses stored on stack
>
> This change uses the Arm v8.3 pointer authentication instructions in
> order to protect return addresses stored on the stack. The generated
> code signs the return address before storing on the stack and
> authenticates it after loading it. This also changes the stack frame
> iterator in order to authenticate stored return addresses and re-sign
> them when needed, as well as the deoptimizer in order to sign saved
> return addresses when creating new frames. This offers a level of
> protection against ROP attacks.
>
> This functionality is enabled with the v8_control_flow_integrity flag
> that this CL introduces.
>
> The code size effect of this change is small for Octane (up to 2% in
> some cases but mostly much lower) and negligible for larger benchmarks,
> however code size measurements are rather noisy. The performance impact
> on current cores (where the instructions are NOPs) is single digit,
> around 1-2% for ARES-6 and Octane, and tends to be smaller for big
> cores than for little cores.
>
> Bug: v8:10026
> Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66239}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,neis@chromium.org,georgia.kouveli@arm.com
Change-Id: I57d5928949b0d403774550b9bf7dc0b08ce4e703
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10026
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051952
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66242}
The list of forward declarations required in the generated file
bit-fields-tq.h is already somewhat unwieldy and will run into serious
problems when we attempt to use enums that are defined within classes,
such as JSDateTimeFormat::DateTimeStyle. After a brief discussion today,
the cleanest solution we arrived at is to generate macros instead.
Change-Id: I654e10efbab5a1a0a340fa565c51ff1da34badaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050830
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66240}
This change uses the Arm v8.3 pointer authentication instructions in
order to protect return addresses stored on the stack. The generated
code signs the return address before storing on the stack and
authenticates it after loading it. This also changes the stack frame
iterator in order to authenticate stored return addresses and re-sign
them when needed, as well as the deoptimizer in order to sign saved
return addresses when creating new frames. This offers a level of
protection against ROP attacks.
This functionality is enabled with the v8_control_flow_integrity flag
that this CL introduces.
The code size effect of this change is small for Octane (up to 2% in
some cases but mostly much lower) and negligible for larger benchmarks,
however code size measurements are rather noisy. The performance impact
on current cores (where the instructions are NOPs) is single digit,
around 1-2% for ARES-6 and Octane, and tends to be smaller for big
cores than for little cores.
Bug: v8:10026
Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66239}
We ensure now that fuzzers don't produce the f.arguments pattern and
instead replace it with a random variable.
No-Try: true
Bug: chromium:1044942, chromium:1020573
Change-Id: I899985f1a238f36d10fb22f76d93b7d5f444eab1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051944
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66238}
Enable --always-promote-young-mc by default. This enforces that the
young generation is empty after a full GC to simplify the implementation of
some features.
For example array buffer sweeping already assumes that this flag is
enabled.
Bug: v8:10064
Change-Id: I9d3873b9eb7bec4de897c5c95bdc514d165265d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051943
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66236}
Clean-up a couple of CAS loops to avoid loading after a compare_exchange
(which updates the old value), and to loosen the memory ordering to
acquire-release to avoid unnecessary fences.
Change-Id: Ifb8e5e5136f687ca5a71417a5d131a7023add054
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050390
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66235}
We were calling setup for both the setup and the run.
Bug: v8:10155
Change-Id: Id60df16ad8c98f443dc1b1a9a2155000999ab815
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039431
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66234}
Un-ignore some files that only failed in obsolete comparisons.
We don't compare eager anymore and console functions are mocked out
in d8 by now. The exponentiation operator bug doesn't repro anymore.
No-Try: true
Bug: chromium:1044942
Change-Id: I0a572836bc9a4a6aa4736447f638a522ff8e8168
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050400
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66233}
Coverage updates are sent as deltas, and this means that it
is very important that the consumer gets /all/ updates;
otherwise, the coverage information will be wrong.
Previously, we introduces the ability into the back-end to
send triggered updates, i.e. updates that are triggered by
the back-end at interesting points in time. These updates
are delivered via an event, and any consumer must process
these events.
This CL introduces a flag to startPreciseCoverage that
controls whether the back-end is allowed to send such
triggered updates on its own initiative. The default is
`false` to maintain backwards compatibility with consumers
that don't yet handle the events.
Bug: chromium:1022031
Change-Id: Ie36a92a3b627b19ea4041f1b8da1ec66c6b9b771
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043798
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66232}
These tests rely on predictable opt & deopt timings. Also add the
--opt flag to tests to force optimization even in configurations that
contain the --no-opt flag.
Bug: v8:9972,chromium:1049982
Change-Id: Ic161d188ebfae9aaae6a160d365413abedfee5f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050402
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66231}
This CL introduces, and turns on by default, compression for snapshots.
The compression is handled in SnapshotCompression, which is a new static
helper class for producing/consuming compressed SnapshotData.
To turn off snapshot compression (accomplished by removing calls of
Compress/Decompress) set the GN arg:
v8_disable_snapshot_compression = true
Bug: chromium:833361
Change-Id: If8abc3662e8473fbd0c94e443946fbea804a305e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846066
Commit-Queue: Sam Maier <smaier@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66230}
It's not sufficient to reset only the modules on the current DFS path.
Bug: chromium:1050164
Change-Id: I00e5e12144ad70ac6371eea5e11590b72feaeecc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049853
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66229}
SourceTextModule::AddAsyncParentModule can allocate so it must be a
static function.
Bug: chromium:1050433
Change-Id: I86e58569d16e626ce3f85cc46ea5f376c2d06f3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050383
Commit-Queue: Adam Klein <adamk@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66228}
This fixes a bug in lazy deopts caused by calls to the callback function
in Array.prototype.reduce and reduceRight.
The deopt continuation expects the *next* iteration's index value but
we actually passed the current iteration's value.
The user-visible effect of this bug was that sometimes, an unexpected
additional call to the callback function would occur.
It was introduced by https://crrev.com/c/1934329.
Bug: v8:9972,chromium:1049982
Change-Id: Icfd2ef076209e20602f54d4662220e1d4c5d07ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049850
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66226}
This CL significantly reduces the size of CSA files generated from
torque by introducing only those Phis at block entry that are
required and otherwise uses defined values directly.
To do so it does:
- Define a DefinitionLocation that represents where a value is
defined.
- For each block compute all the definitions that reach that
block and introduce a phi iff the reaching definitions for a value
are not the same for all predecessor blocks.
- In CSAGenerator map all DefinitionLocations to variables, such that
if the same value is used in multiple blocks, it is mapped to the
same variable without the need to pass it along the jump. This
reduces both the arguments passed to Goto, Branch, ... and the
variables that need to be passed to Bind when the block's label is
bound. This reduces the number of temporary variables
significantly. Temporaries are declared outside of blocks now
in order to be accessible from other blocks.
Drive-by changes:
- Sequences of SetSourcePosition calls are merged if no output is
generated between them.
- Dead blocks are no longer generated in release builds.
Bug: v8:9861
Change-Id: I5c30e5376e93c424c3ebfc5144a08592d77ae61f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037444
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66225}
The Object::SetElement and JSObject::GetElement were
the GC suspects.
Fixed: v8:9995
Change-Id: Ia1f794188f08f0e2543a88eb4dc7a8b06dcb3deb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050391
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66223}
This reverts commit c0fbfcd81c.
Reason for revert: Fix found.
Original change's description:
> Revert [gasm] Implement ReduceArrayPrototypeReduce using the graph assembler
>
> Reverting due to a nondeterministic correctness issue bisected to this
> change. The intent is to reland once we fully understand and have
> fixed the problem.
>
> The original CL landed in https://crrev.com/c/1934329.
> The revert on master is https://crrev.com/c/2049763.
> The revert on 8.0 is https://crrev.com/c/2049764.
>
> Bug: v8:9972,chromium:1049982
> Change-Id: I171624bdeb18831e70869ae806c73529c240be4a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049763
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66215}
TBR=neis@chromium.org,jgruber@chromium.org
Change-Id: Id12a01dc72558639b26af58ff56cd0b11916eec2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9972, chromium:1049982
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050395
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66222}
Before this CL array buffer counters were only decremented at the next
GC. This CL makes freed_bytes_ an atomic variable which is incremented
by the concurrent sweeping task. The main thread now also inspects this
value when adding new JSArrayBuffers to update counters sooner.
Bug: v8:10064
Change-Id: Ibcb245b541e806b95a3c2c42d3cc3affe7739e4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047043
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66221}
Adds DCHECK to Factory::AllocateRawWithImmortalMap to assert that the
Map passed in is read_only_space, since it's passed in as a raw object.
Bug: chromium:1049866
Change-Id: Ia7c6d5c99a4bc790ebcfb06e5ed55340964a5612
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049846
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66220}
This reverts commit 14d1b9e944.
Reason for revert: Increases RuntimeStats/Group-JavaScript/duration
Original change's description:
> [compiler] Make StateValuesAccess methods inlinable
>
> This moves several simple StateValuesAccess methods as well as
> SparseInputMask::InputIterator::IsReal into their header files so they
> can be more easily inlined. This gives about a 7% improvement to the
> BackgroundSelectInstructions runtime call stat.
>
> Also marks some methods called by the new methods as V8_PRIVATE_EXPORT
> so component build test can build.
>
> Bug: v8:10051
> Change-Id: I3e34977a4fa660d3f4f55fd4f2c0b2370d5d2bc2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023559
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66078}
TBR=neis@chromium.org,delphick@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:10051
Change-Id: I9168b524bc06562906a12a6ec0e948d6f90d4a7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050387
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66219}
Reading an object property can allocate a HeapNumber (even with
unboxed double fields turned off: we still use MutableHeapNumbers
to store properties).
Bug: chromium:1049859
Change-Id: I82228ccb98403b3db82671743f51b2e23f6636d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050385
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66218}
The assumtion that V8 has no output differences within a single line
before a stack overflow, didn't hold. The prefix of e.g. console.info
can lead to a difference in a recursive call.
This change makes foozzie's output capping before a crash work on the
level of characters instead of lines to fix this.
No-Try: true
Bug: chromium:1050942
Change-Id: I13f747caf4f5848d40c31bd4232811285bab3c17
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049844
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66217}
Reverting due to a nondeterministic correctness issue bisected to this
change. The intent is to reland once we fully understand and have
fixed the problem.
The original CL landed in https://crrev.com/c/1934329.
The revert on master is https://crrev.com/c/2049763.
The revert on 8.0 is https://crrev.com/c/2049764.
Bug: v8:9972,chromium:1049982
Change-Id: I171624bdeb18831e70869ae806c73529c240be4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049763
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66215}
Adds support for off-thread allocation to Script allocation and
line-end calculation.
This includes adding support for keeping/merging a script list on
the OffThreadIsolate, and adding syntactical support for logging
(in the future this could do actual logging).
Bug: chromium:1011762
Change-Id: Id90f2ad7458e90e06f6926f1fce7ef7a1ef50b3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2046884
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66213}
Port 9d3dc6f219
Original Commit Message:
FunctionEntry StackChecks is one of the two cases where we generate a
StackCheck bytecode. In these cases, we do stack check against the js
limit (not to be confused with the real js limit). Their purpose is to
be able to interrupt the running code.
We can omit the FunctionEntry StackCheck by embedding its code into
the InterpreterEntryTrampoline builtin. We save one bytecode per
interpreted function.
This change has rippling effects for optimized code, as well as the
deoptimizer.
R=solanes@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: If797a8acba7581c9c388ac09b5554c774c5993a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2048124
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66210}
Add CHECKs to make sure that ArrayBufferSweeper is only active when
v8_enable_array_buffer_extension is set to true.
Bug: v8:10064
Change-Id: I609d5e1230dca52fd8555d4401c3f60faf4c266c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047047
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66209}
Deprecate the following explicit FinalizationGroup APIs in favor of
automatic handling of FinalizationGroup cleanup callbacks:
- v8::Isolate::SetHostCleanupFinalizationGroupCallback
- v8::FinaliationGroup::Cleanup
If no HostCleanupFinalizationGroupCallback is set, then
FinalizationGroup cleanup callbacks are automatically scheduled by V8
itself as non-nestable foreground tasks.
When a Context being disposed, all FinalizationGroups that are
associated with it are removed from the dirty list, cancelling
scheduled cleanup.
This is a reland of 31d8ff7ac5
Bug: v8:8179, v8:10190
Change-Id: I704ecf48aeebac1dc2c05ea1c052f6a2560ae332
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045723
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66208}
Port 86d4b9f6ca
Original Commit Message:
Each assembler has it's own way to place breakpoints:
- stop() for arm, mips*, ppc* and s390.
- debug() for arm64.
- int3() for ia32 and x64.
We can mandate a macro-assembler `DebugBreak()` method that all should
implement so one can place a breakpoint in a portable way using a
macro-assembler. This way also assemblers are in line with TurboFan, CSA, Torque
and Liftoff which all have a DebugBreak() facility.
R=pierre.langlois@arm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: If2fb5ed99b4477142579e29fc5288d0768fd48c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047463
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66207}
FunctionEntry StackChecks is one of the two cases where we generate a
StackCheck bytecode. In these cases, we do stack check against the js
limit (not to be confused with the real js limit). Their purpose is to
be able to interrupt the running code.
We can omit the FunctionEntry StackCheck by embedding its code into
the InterpreterEntryTrampoline builtin. We save one bytecode per
interpreted function.
This change has rippling effects for optimized code, as well as the
deoptimizer.
Bug: v8:10149, v8:9977, v8:9960
Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66206}
We should not allow runtime functions that perform extra checks in
differential fuzzing, as there we ignore crashes and dchecks entirely.
Furthermore, this change whitelists some runtime functions for getting
more coverage.
Bug: chromium:1044942
Change-Id: Ie5d90bb53bc2d2bacc6635b1dcbe466605b33e12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041444
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66205}
Introduce separate counters for young and old array buffer bytes. They
are used to keep the counter stable during sweeping when the array
buffer lists are moved to the concurrent thread for sweeping.
Bug: v8:10064
Change-Id: I0f11a634341873b4d21759c284c55beb26fe30a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045511
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66204}
This makes creating whitelisted runtime functions more permissive on
fuzzers (when --allow-natives-for-fuzzing is passed).
- Runtime functions with too few arguments are replaced with undefined.
- Superfluous arguments are ignored.
This reduces syntax-error rate on fuzzers. Also prevents
dcheck errors when fuzzing debug builds and fuzzers use too many
arguments for runtime functions.
Bug: chromium:1044942
Change-Id: I23b45398421c50bc82d1e8bfdf019f565253db96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039352
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66202}
This groups atomicops by type, removes an unused atomicop, and fixes
comments.
Change-Id: I9621ac4512d019ae9d0ce4f7e38c81011d46aa37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047044
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66201}
Make the NextScriptId value incrementing method thread-safe, using
CompareAndSwap primitives. This will allow it to be used in the
future for off-thread compilation.
Bug: chromium:1011762
Change-Id: I5b449e75c7dc63d24fa045ae880b0680b54c2f3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2046883
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66200}
Take advantage of the HandleOrOffThreadHandle implicit conversions where
applicable.
Bug: chromium:1011762
Change-Id: Iaf49d9098368b402e1cd3d991629d3f5e718f28e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2046885
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66199}
Each assembler has it's own way to place breakpoints:
- stop() for arm, mips*, ppc* and s390.
- debug() for arm64.
- int3() for ia32 and x64.
We can mandate a macro-assembler `DebugBreak()` method that all should
implement so one can place a breakpoint in a portable way using a
macro-assembler. This way also assemblers are in line with TurboFan, CSA, Torque
and Liftoff which all have a DebugBreak() facility.
Change-Id: Ic4332bd19ca4db53e01441d54af6632c2c1189f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020954
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#66198}
Make Scope allocation and ScopeInfo creation Isolate-templated. This
includes making SourceTextModuleInfo allocation templated -- modules
aren't currently streamed off-thread, but will hopefully be in the
future, so this future-proofs them against that.
Bug: chromium:1011762
Change-Id: I8954e08e8e81489eb821b5f62ec35a5be31fce09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043790
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66197}
When delaying finalization we considered the maximum of the current time
to task and the recorded average. In case there's no recorded average
the GC would consider the current time to task as estimate which is too
aggresive as V8 may never get a task executed.
Be fully conservative about recorded task times and bail out in such
cases.
Bug: chromium:1049957
Change-Id: Ibaac242f72459341a170af80e63fb2266f91b0eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043809
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66196}
Update external memory counters when using ArrayBufferExtensions. In
case the array buffers are swept concurrently, the counters are updated
at the beginning of the next minor/full GC. A subsequent GC is going
to update counters faster.
ArrayBufferExtension now stores the accounting_length such that
the sweeper always knows how much memory to deduct from the external
memory on destruction.
ArrayBufferList now also tracks the size of all ArrayBuffers in it.
Bug: v8:10064
Change-Id: I50a8b1180aa837b6932f834df1610255bd2bd9fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041441
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66195}
Make sure we can't get the Isolate for writable off-thread space
objects, to avoid leaking the Isolate into off-thread compilation.
Bug: chromium:1011762
Change-Id: I5c4316e751736b8c8235fdcc8949d52b78313f38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043791
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66194}
The logic for V8 GC normally only takes the external memory growth
since last mark-compact into account. Unfortunately, the amount of
external memory recorded at the end of MC is often too high. The
reason is that it might take a while for the external memory
associated with the GCed objects to be released (e.g. V8 itself post a
task to release external memory for ArrayBuffer backing stores). In a
worst case scenario GC is driven only by external memory and none of
the external memory is released by the end of the MC. Then each MC
will record the external memory at its highest point and the GC logic
will allow the external memory to grow a bit higher each time which
can lead to excessive memory use.
This patch improves the situation a bit by calculating the growth from
the lowest external memory seen since the last MC. That way the growth
calculation will be offset from a level presumably closer to the
intended one (to what it would have been if the external memory
associated with the GCed objects was released during the MC). Now,
this fix is not perfect because it can be thrown off by external
memory growth occurring before the lingering memory is
released. However, it seems to work rather well in practice (e.g. when
playing MSE video on YT).
Bug: v8:10185
Change-Id: Ifcdd87eb45f3ae4a99d2aeec667c3ae4ca9a52b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042711
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66193}
