Int32MulWithOverflow on arm64 uses a cmp to set flags rather than
the multiply instruction itself, thus we can use a left shift when
the multiplication is by a power of two.
This provides 0.15% for Speedometer2 on a Neoverse-N1 machine,
with React being improved by 0.45%.
Change-Id: Ic8db42ecc7cb14cf1ac7bbbeab0e9d8359104351
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829472
Commit-Queue: George Wort <george.wort@arm.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82499}
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}
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}
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}
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}
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}
This is a reland of commit cf765fc348
Original change's description:
> [Temporal] Use double instead of int32_t for input of BalanceTime
>
> To avoid overflow int32_t in the math of balancing time.
>
> Bug: v8:13182, v8:11544
> Change-Id: Ib76cf95bbd4f9b47efd6921a67b09d3024e72b13
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827310
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82409}
Bug: v8:13182, v8:11544
Change-Id: I7550b3a7186beed0e32e95a41cae87030d0c5a7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827671
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82445}
to get rid of the pattern
```
EnsureHash();
uint32_t field = raw_hash_field();
```
which requires an additional load and might be misleading in the
presence of forwarding indices for shared strings, as raw_hash_field()
can return a forwarding index, whereas EnsureRawHash() will always
return a computed hash value.
Bug: v8:12957
Change-Id: I33426fef433f774fb323d4381e784c1037fb6fbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829469
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82441}
This reverts commit a19316d9d7.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/22670/overview
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: I14994e11ff5ffaba70b93d977d40dd2f6e9e5d35
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829474
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82438}
The existing version for paged spaces simply reset the freelist, which
doesn't work for tests that require actual objects in the space.
The version for new space also doesn't work because it assumes
everything after top is free space.
Fill the space with FixedArray by iterating over the freelist and
creating an object in place of each freelist entry.
This method actually fills the space, so that we can also use it to
force page promotion.
Bug: v8:12612
Change-Id: Ie0d73e846bbf688ea52030be29e0587b2f37ed4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3823135
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82437}
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}
This adds `extern.internalize(ref null extern): ref null any` to wasm
which unpacks the wrapped wasm object if the js-interop flag is not set.
I31 values are still wrapped in object wrappers and don't use SMIs.
Bug: v8:7748
Change-Id: Ie4a4507961d0ad41caf430054a3d341f474b8e66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819645
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@{#82426}
This has been broken even prior to the any <-> extern split.
The code decided to use the generic wrapper for type any even though
the generic wrapper doesn't support wrapping the return value of functions
and unwrapping arguments passed to it.
Bug: v8:7748
Change-Id: I9dbb893cc4bc4f2bb789b3b3a9addd0208d526ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3826056
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82424}
Bug: v8:13181
Change-Id: I8eaa84ffc408225ee28dca17607b940fd3f34977
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3826068
Commit-Queue: Adam Klein <adamk@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82414}
This reverts commit cf765fc348.
Reason for revert: fixes more tests than expected in test262:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20shared/49412/overview
Original change's description:
> [Temporal] Use double instead of int32_t for input of BalanceTime
>
> To avoid overflow int32_t in the math of balancing time.
>
> Bug: v8:13182, v8:11544
> Change-Id: Ib76cf95bbd4f9b47efd6921a67b09d3024e72b13
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827310
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82409}
Bug: v8:13182, v8:11544
Change-Id: Id7dd491b4485d13b0e2cc6aae8603479c7949ce8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827670
Auto-Submit: Adam Klein <adamk@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@{#82413}
To avoid overflow int32_t in the math of balancing time.
Bug: v8:13182, v8:11544
Change-Id: Ib76cf95bbd4f9b47efd6921a67b09d3024e72b13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827310
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82409}
Remove the unnecessary int64_t version of RoundNumberToIncrement
and remove the unneeded RoundHalfAwayFromZero. Change the type of the
increment to double from int64_t.
split from cl/3750098
Bug: v8:11544
Change-Id: I591486c472e9c1343306ff9a1d0384d06fe01835
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3824194
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82403}
So far, we decoded instructions with the 0xFB prefix as two-byte, i.e.
a single "u8" byte following the prefix.
This patch changes that to 0xFB + LEB, which is how all prefixed
instructions are supposed to do it. Currently this makes a difference
only for the stringref proposal (instructions 0x80 through 0xb3).
It has the unfortunate consequence that all stringref instructions need
three bytes for now. We expect them to go back to a two-byte encoding
scheme (while remaining LEB compliant) when their final encoding is
decided.
Bug: v8:12868
Change-Id: I603f60adae88e9b985cb65288d9eeb7f98da8138
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3825887
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82400}
This is a reland of commit 9d36b2dd0d.
The test case is fixed to actually protect a part of the data section
instead of the stack (which was unintended and could lead to segfaults).
Original change's description:
> [base] Add new API to protect data memory
>
> This adds a new {base::OS::SetDataReadOnly} method, which is similar to
> {SetPermissions(kRead)}, but using another system call on Windows such
> that it works on pages in the data segment.
> {VirtualAlloc} will fail if called on a page of the data section,
> whereas {VirtualProtect} succeeds. For the general {SetPermissions}
> API we still want to use {VirtualAlloc} though, as it also changes the "committed" state of the pages.
>
> Note that we do not add a platform API for this, as the memory was
> never allocated through the platform. We just directly protect it in
> V8.
>
> R=mlippautz@chromium.org
>
> Bug: v8:12887
> Change-Id: If83bf6e5c500cc5cf08c76d04dfac5e2b4d35a2d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820482
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82349}
Bug: v8:12887
Change-Id: Ib7c24b43b53d568dafb4a56cf8db7479c784e8d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3825889
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82398}
... in compiler and other components.
Bug: v8:11880
Change-Id: I3a51c33499e7c7169f171c4be0600d7822dafc27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3825883
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82391}
This CL removes the bailout when trying to collect the scope info
for the class member initializer function. While this might not have
worked previously, now we only need to tweak the scope search
slightly to fix this. Class member initializer functions never
have their own context but instead us the class context. That means
that most of the logic in debug-scopes.cc doesn't really matter and we
only need to initialize the ScopeIterator properly with the class
context and the member initializer JSFunction.
Note that this still does not fully fix bug 1350842. That is because
we still run into a DCHECk when paused at a `new class { ... }`
statement. We'll fix that in a separate CL.
R=bmeurer@chromium.org
Bug: chromium:1350842
Change-Id: Id128b10676a5aa8a77309735e755e485f2c14446
Fixed: chromium:1246889
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3825881
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82387}
This function should properly forward any exceptions it encounters,
instead of silently swallowing them. Being an API function, that
means moving them from "pending" to "scheduled" state.
Fixed: v8:13123
Change-Id: I20b0782fd806e456f14dda84100000c857481d09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3825880
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82386}
This is a reland of commit 532ca59910
Fix interger overflow when result_location is invalid in
MaglevCompiler::InReturnValues.
Original change's description:
> [maglev] Support LdaModuleVariable and StaModuleVariable
>
> Bug: v8:7700
> Change-Id: I036ac71324e0c1c96a4da4aacdb5a6718726db31
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3821203
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: 王澳 <wangao.james@bytedance.com>
> Cr-Commit-Position: refs/heads/main@{#82347}
Bug: v8:7700
Change-Id: I24f56691eefd1c6cb695fedd3b5c14264bb17943
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3824942
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82379}
We have a bug report from 2018 that no longer reproduces on ToT.
This CL adds a regression bug regardless to make sure we don't
re-introduce the bug that got fixed as a side-effect.
R=kimanh@chromium.org
Fixed: chromium:1246896
Change-Id: I8f9fdcbf7051b23e03cbbfc572771a410f70ad37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3822668
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82372}
