This fixes a compile error in C++20 with comparison operator reordering.
Also does a little misc. cleanup to the adjacent code.
Bug: chromium:1284275
Change-Id: I1999c4ef2e8a201d2f1270347fe12c33c961c011
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3830987
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82497}
The {vmar.protect} API used for {SetPermissions} fails when called on
data memory with error -10 (ZX_ERR_INVALID_ARGS).
Skip fuchsia until we figure out the right API to use there.
R=cbruni@chromium.org
Bug: v8:13194
Change-Id: I20754f7212a892b8440f29658bf3db40f7745fe9
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3833820
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82494}
This is a reland of commit a19316d9d7
- Revert malloc_usable_size() changes temporarily to land them in
isolation.
- Add cosmetics from https://crrev.com/c/3827876
Original change's description:
> [heap] Rework Worklist base type
>
> Worklist uses a singly-linked list of segments to hold entries.
> Segment size was based on a compile-time constant but already stored
> in the segment itself.
>
> Rework the segments to query `malloc_usable_size()` on allocation and
> adjust the capacity properly. For PartitionAlloc, it turns out that
> there's ~20% more capacity available for the 64-element segments.
>
> This slows down actual allocation of the segments with the upside of
> improving utilization and requiring 20% less segments.
>
> Change-Id: Ib8595c3fb9fb75b02e4022f6c525bb59a2df7ab7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3826047
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82432}
Change-Id: Ic8c5257cfe3c347b11eea5c513ca7f62e09f637f
Bug: v8:13193
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829475
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82493}
This adds `extern.externalize(ref null any): ref null extern` to wasm
which packs wasm objects into JS objects if the js-interop flag is not set.
This is the counterpart to extern.internalize introduced in
50ec8a11f2.
Bug: v8:7748
Change-Id: I67b8fe6d70b9f526ff6c43b0a4d7861c7ff5dad0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3825879
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82492}
This CL fixes a CHECK that checks the wrong thing. Specifically when
we `Advance` the debug::PropertyIterator it can throw an exception.
We have a CHECK that verifies that a corresponding v8::TryCatch catches
the exception when the return value indicates this. Unfortunately, the
CHECK was looking at the wrong v8::TryCatch scope.
R=jarin@chromium.org
Bug: chromium:1353051
Change-Id: Ic52e4efd44b89f8e4d1f6acace234c6065e081cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829543
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82489}
Introduce common bottleneck for all incremental marking step
invocations from a task context. This will later be used to move
code out of IncrementalMarking::Step.
This is a reland of https://crrev.com/c/3822682. This CL now always
schedules normal tasks instead of delayed ones in order to keep current
behavior.
Bug: v8:11708
Change-Id: I0dc378879177458a6429ea0b3acd3ee45b499240
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3833814
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82486}
M1 still seems to have some performance regressions on
MotionMark/multiply.
Bug: chromium:1325007
Change-Id: I12ce44b8cef646f09a3c74ba533dfee8dffdd2ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829540
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82485}
The external pointer table is already to some degree self-compacting: as
the freelist is sorted in ascending order, free entries at the start of
the table should quickly fill up. However, any live entry at the end of
the table makes it impossible to shrink the table, thereby causing
higher memory consumption. To solve this, this CL implements a simple
table compaction algorithm, used when the freelist has become
sufficiently large (currently >= 10% of the table capacity):
- The goal of the algorithm is to shrink the table by freelist_size/2
entries at the end of compaction (during sweeping).
- At the start of the marking phase, the compaction area is computed as
roughly [capacity - freelist_size/2, capacity).
- When an entry is marked as alive that lies inside the compaction
area, a new "relocation entry" is allocated for it from the freelist
and the address of the handle for that entry is stored in that entry.
If there are no more free entries before the compaction area,
compaction is aborted. This is expected to happen rarely and is
logged into a histogram.
- During sweeping, all relocation entries are "resolved": the content
of the old entry is copied into the new entry and the handle is
updated to point to the new entry.
- Finally, the table is shrunk and the last initial_freelist_size/2
entries are decommitted.
See also the comments in the ExternalPointerTable class for more details.
Bug: v8:10391
Change-Id: I28d475c3596590e860421f0a054e2ad4dbebd487
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3794645
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82484}
Consider the function:
function foo() {
debugger;
let y = 1;
}
V8 will elide the hole initialization for 'y'. When we pause at the
debugger statement, then 'y' evaluates to 'undefined'.
This CL fixes this in the ScopeIterator. When we encounter local
variables with an `undefined` value we check the static scope
information if we are stopped *before* the variable's initializer.
If yes, then we are in the variable's TDZ and report
"value unavailable".
Drive-by: Mark `GetSourcePosition()` as `const` to make it available
in the visitor method.
R=bmeurer@chromium.org
Bug: chromium:1328681
Change-Id: I8b966eaa2af64a35a58095a744440851760921a0
Fixed: chromium:1303493
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829539
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82483}
This CL replaces the AllocateExternalPointerEntries methods with
per-field init_##fieldname methods for every external pointer field.
These now initialize the field by allocating the external pointer table
entry for it and also set the initial value. This saves one memory write
in the typical case (what used to be AllocateExternalPointerEntries
followed by a set_##fieldname) and removes some code that can be
factored out into the (DECL_)EXTERNAL_POINTER_ACCESSORS macro.
Bug: v8:10391
Change-Id: Iac937316322910de0a8bb99b33592eca8c57a4a6
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810344
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82482}
When freezing flags, not only remember this in a global variable, but
also actually memory-protect the memory that holds the flag values.
R=cbruni@chromium.org
CC=sroettger@chromium.org
Bug: v8:12887
Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
Change-Id: I2ae638790d1f08f4bcc1b7e6cb5970e4e7463aad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811286
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82478}
Remove the following deprecated functions:
include/v8-inspector.h:364 v10.3 Use version with client_is_trusted argument
include/v8-locker.h:130 v10.3 This method will be removed.
include/v8-message.h:90 v10.3 Use GetHostDefinedOptions
include/v8-script.h:51 v10.0 Use HostDefinedOptions
include/v8-script.h:671 v10.0 Use CompileFunction
Output generated by tools/release/list_deprecated.py.
Remove CompileFunctionInContext for chrome and only implement it if
V8_SCRIPTORMODULE_LEGACY_LIFETIME is defined.
Change-Id: I33dd3665220f484e277e66f340e17ed2c3b49916
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702449
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82476}
TotalDurationNanoseconds previously return a double to represent the
total duration nanoseconds, but the value could be easily bigger than
the precise value a double can represent. A double can precisely
represent integer to 2^53, which is only about 104 days if that value
is nanoseconds. So we need to change the return type to BigInt.
Refactor BalanceDuration to merge common code.
Change JSTemporalDuration::Compare to use the BigInt version of
TotalDurationNanoseconds
Change the call site of TotalDurationNanoseconds in RoundDuration
Add newly defined BalancePossiblyInfiniteDuration and change
BalanceDuration to call it.
Spec text:
https://tc39.es/proposal-temporal/#sec-temporal-balancepossiblyinfinitedurationhttps://tc39.es/proposal-temporal/#sec-temporal-balancedurationhttps://tc39.es/proposal-temporal/#sec-temporal-totaldurationnanoseconds
Split from changes in cl/3750098
Bug: v8:11544
Change-Id: Ia4ca8f9bdba49c3a5e54edeef0d2a5833b0002a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3824658
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82475}
Make sure there is no background GC when setting flags.
Bug: v8:12612, v8:13185
Change-Id: I0a2d4796abe265defa00d86f826003eb048e5bf1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829482
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82474}
This CL builds upon https://crrev.com/c/3284887 (and partly reverts it).
Class literals are a bit iffy when it comes to source position and
debugging. Mainly the debugger assumes the following invariant:
When we are paused inside a class scope, then we expect the class's
BlockContext to be pushed already. On the other hand, when we are
paused outside a class scope in a function, we don't expect to find
the class's BlockContext.
The problem is that there are cases where we can either pause
"inside" or "outside" the class scope. E.g.:
* `var x = class {};` will break on `class` which is inside
the class scope, so we expect the BlockContext to be pushed
* `new class x {};` will break on `new` which is outside the
class scope, so we expect the BlockContext to not be pushed
yet.
The issue with the fix in https://crrev.com/c/3284887 is that it
adjusted the break position for the bytecode of class literals to
ALWAYS be after the BlockContext is pushed. This breaks the
second example above. We need to tighten the fix a bit and only
defer the break position if the "current source position" is
inside the class's scope. This way we always guarantee that the
BlockContext is pushed or not, depending if the source position
that corresponds to the break position is inside or outside the
class's scope.
Note 1: The CL updates a lot of the bytecode expectations. This
is because the class literals are often the first statement in
the snippet so we don't need to defer the break position.
Note 2: We add a mirrored debugger test to the inspector test so
the fuzzer can have some more fun.
Fixed: chromim:1350842
Change-Id: I9b5a409f77be80db674217a685a3fc9f8a0a71cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827871
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82473}
Once lazy compilation lands we want to continue testing the eager
compilation configuration. For that we add --no-wasm-lazy-compilation to
the "stress" variant.
Bug: v8:12852
Change-Id: I1777aaeb1c8cec0359128ed4b3d34a21aa3ce37e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810249
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82470}
The slow paths of the Array.prototype methods in the
change-Array-by-copy proposal don't need to be inlined as macros. Make
them builtins where possible.
This CL also driveby fixes the fast path for toSpliced to only apply
when the returned copy's length is <= kMaxFastArrayLength.
Bug: v8:13035
Change-Id: I4034d5d40d7db14d86b33a6f1047e1b17781321a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3830287
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82465}
Bug: v8:12781
Change-Id: I759024fb18ee596ecb678e5b70c95235ea91e520
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827126
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82464}
Store the is_marking_flag_ in the IsolateData to improve the generated
code for the RecordWrite builtin. This allows to load the value of the
flag directly using the root register, instead of loading that flag's
address first using the root register and only then loading its value.
Bug: v8:11708
Change-Id: Id4076a7e519c5f8126e310771c0ccd958dc07278
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780536
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82456}
This is a reland of commit a1b863c130
Original change's description:
> [heap] Introduce per-thread storage for concurrent sweeping
>
> Introduce ConcurrentSweeper as indirection between SweeperJob and
> Sweeper to hold per-thread state during sweeping.
> This will be used by MinorMC sweeping to hold the pretenuring feedback
> map.
>
> Bug: v8:12612
> Change-Id: Ib363339f9109b405e4cae7f2c08cb4f0eacff8d0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829466
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82442}
Bug: v8:12612
Change-Id: Ic475d0a8a6e9f9e8b5945bb8d28588db1d524510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829480
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82454}
