In C++20, u8"" generates a const char8_t*, not a const char*. Since ""
accepts UTF-8 already, just switch to it.
Bug: chromium:1284275
Change-Id: I873321a62a4d9e32b3b463913a3bc10231db3db3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630347
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80382}
This CL adds prefixed store scalar and floating point
instructions to the assembler and uses it during code generation
if the processor supports it. They have also been added to the disassembler and the simulator.
Change-Id: I0b9e0758f17ca6b86d4f2f2bb36be87fba14ecb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3626173
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80381}
1. Move the use of MAYBE_RETURN to MAYBE_ASSIGN_RETURN_ON_EXCEPTION_VALUE
if possible.
2. Remove some MYABE_RETURN in the wrong spot and therefore fix some tests.
3. Change Intl::GetTimeZoneIndex() to return Maybe<int32_t> as index and use
< 0 value to indicate not getting index to make the function signature
simpler.
Bug: v8:11544
Change-Id: I685cbff142e9dea69ef316a1bc180730aef5aec8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625839
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80379}
This prevents ambiguity errors in C++20 due to ADL when casting types in
std::, which gains std::bit_cast<>().
Bug: chromium:1284275
Change-Id: I25046d1952a9304852e481ad8b84049c6769c289
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625838
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80378}
The write protection of code memory with mprotect is too expensive for
lazy compilation. As the usefulness of this memory protection is
limited anyways, this CL disables the memory protection in case lazy
compilation is enabled.
Bug: v8:12852
Change-Id: I4c56d4021a7b594e24a4d3d28a130a309c56de38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3627596
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80377}
This is a reland of commit 507fa4d7f5
This CL moves the NewJSObjectFromMap after deserializing object properties with dictionary map and fixes the DCHECK failure in JSReceiver::HasFastProperties when triggering GC.
Original change's description:
> [web snapshot] Add support for object with dictionary mode
>
> This CL adds the serialization support for object properties
> with dictionary map. Shape id is used to distinguish between if the object has dictionary map. And add TODO to support “no map objects” which can have fast map and “objects with map” which needs to be turned to dictionary mode.
>
> Bug: v8:11525
> Change-Id: If3eb4195115a41d4a3f6cc7372924b982ca96fc1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3621593
> Commit-Queue: 王澳 <wangao.james@bytedance.com>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80366}
Bug: v8:11525
Change-Id: I88422d698aa03fb7d3b21b5709eec2d0cf306256
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629738
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80374}
Based on the robust test suite for checking property "has/in" queries, with the intention
of measuring the performance of accessing getOwnPropertyDescriptor.
Background: getOwnPropertyDescriptor and defineProperty were identified as hot code taking up
a significant chunk of startup time in a customer application. This benchmark aims to measure
the difference made by a modifying Object.getOwnPropertyDescriptor.
By current measurements, the geometric mean time of the new version is typically 1/6 that of
the current upstream implementation, using this test specifically (however, only on arm64 /
Apple M1... On Linux/x64, the results look more reasonable at a roughly 5-12% improvement in
score).
In its current form, this benchmark does very little to attempt to verify the results of the
object, which may result in branches being discarded in Turbofan (but given the enormous
difference between x64 and arm64, I'm not positive this is what is happening, and have not yet
verified this).
BUG=
Change-Id: I0f10735315313ed97efd00fcccaedc1272d4d314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3624979
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80373}
Consider the following
* A ValueNode has inputs A and B
* Input A has later uses, input B doesn't
* The ValueNode's result must be in the same register as A
It can then happen that UpdateUses frees B, and the result allocation
emits a gap move from A's register to B's old register (now free) to
preserve the value of A when the ValueNode writes into its register.
This gap move is emmitted before the ValueNode start, which means that
it clobbers B.
Now, UpdateUses only clears registers _after_ node result allocation, so
that the known free registers are still the ones before updating uses.
Done naively, this would have bad consequences -- in the case where A
has no later uses, it would still force the regalloc to save its value
thinking that it is still live. So, this patch also introduces a concept
of "AllocationStage" where we're either allocating at the start or end
of a Node. Inputs are allocated at the start, results at the end. When
walking registers during an allocation, nodes whose lifetimes end at the
current node are considered to be dead at the "end" allocation stage,
and we are allowed to a) use their registers, and b) drop them without
preserving their value.
Bug: v8:7700
Change-Id: I5ca764ed04b12269f189577e81eb7e2a27cd1b09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625978
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80371}
This reverts commit 507fa4d7f5.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/38308/overview
Original change's description:
> [web snapshot] Add support for object with dictionary mode
>
> This CL adds the serialization support for object properties
> with dictionary map. Shape id is used to distinguish between if the object has dictionary map. And add TODO to support “no map objects” which can have fast map and “objects with map” which needs to be turned to dictionary mode.
>
> Bug: v8:11525
> Change-Id: If3eb4195115a41d4a3f6cc7372924b982ca96fc1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3621593
> Commit-Queue: 王澳 <wangao.james@bytedance.com>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80366}
Bug: v8:11525
Change-Id: I0d236a9937a5942b387553a61991716321b063e6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629541
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>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80368}
This CL adds the serialization support for object properties
with dictionary map. Shape id is used to distinguish between if the object has dictionary map. And add TODO to support “no map objects” which can have fast map and “objects with map” which needs to be turned to dictionary mode.
Bug: v8:11525
Change-Id: If3eb4195115a41d4a3f6cc7372924b982ca96fc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3621593
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80366}
This CL cleans up the existing experimental implementation of
conservative stack scanning. It retains the object start bitmap, to
evaluate it as a mechanism for resolving inner pointers, and the
conservative stack scanning visitor (which is currently not used).
The flag v8_enable_conservative_stack_scanning is kept and will be
used for experimental purposes. It currently does not imply any
other flag.
Bug: v8:10614
Bug: v8:12851
Change-Id: Id0ae0f437ed2601eed9ec634d2d1dd2f030d814e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602516
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80365}
WASM only supports simd128, but modern CPUs support
up to 256 bit vector register or more, we will add an
experimental feature to do 256 bit re-vectorization
in Turbofan pipeline, this patch add simd256 machine
representation.
Bug: v8:12716
Change-Id: I1e6a3f2afa0a457fca2c261216f4113d0ed5b818
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3534456
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Jie Pan <jie.pan@intel.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80361}
This reverts commit 2b79eefed3.
Reason for revert: Speculative revert because of https://crbug.com/1322305
Original change's description:
> Reland^2: [heap] Store size with invalidated object
>
> This is a reland of commit 23b2d571a7
>
> When updating pointers during a full GC, a page might not be swept
> already. In such cases there might be invalid objects and slots
> recorded in free memory. Updating tagged slots in free memory is fine
> even though not strictly necessary.
>
> However, the GC also needs to calculate the size of potentially dead
> invalid objects in order to be able to check whether a slot is within
> that object. But since that object is dead, its map might be dead as
> well which makes size calculation impossible on such objects. The CL
> changes this to cache the size of invalid objects. A follow-up CL will
> also check the marking bit of invalid objects.
>
> Reason for reverts:
>
> Revert #2: In-object slack tracking on JSObjects doesn't update the
> cached size of invalidated objects. The fix here was to stop
> invalidating recorded slots on JSObjects at all and avoid that problem
> completely (see https://crrev.com/c/3620274).
>
> Revert #1: Not all size changes go through NotifyObjectLayoutChange, so
> https://crrev.com/c/3607992 introduced NotifyObjectSizeChange as a
> bottleneck for object size changes/right-trimming. This method is
> now used to update the size of invalidated objects.
>
> Bug: v8:12578, chromium:1316289
> Change-Id: I0478d04601c0270ddb39419ca6cf98719951eb4d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3623542
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80344}
Bug: v8:12578, chromium:1316289
Change-Id: I6dd2dd13583123b9cb7933b15e2113fddc0c0b0b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3627511
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80357}
This is temporary until we update our infra to always use --turbofan
Change-Id: Ie1ca8ce2cae6744515d9810ae4f57f00c8670e36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625977
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80355}
In the future we may want to cache this in a separate slot to turbofan
code, but for now cache maglev code in the same optimized code slot on
the feedback vector.
Bug: v8:7700
Change-Id: Idd40a024cc9beb9b4da06a88a3789d822ddd4ab7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3622916
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80354}
This is a reland of commit 23b2d571a7
When updating pointers during a full GC, a page might not be swept
already. In such cases there might be invalid objects and slots
recorded in free memory. Updating tagged slots in free memory is fine
even though not strictly necessary.
However, the GC also needs to calculate the size of potentially dead
invalid objects in order to be able to check whether a slot is within
that object. But since that object is dead, its map might be dead as
well which makes size calculation impossible on such objects. The CL
changes this to cache the size of invalid objects. A follow-up CL will
also check the marking bit of invalid objects.
Reason for reverts:
Revert #2: In-object slack tracking on JSObjects doesn't update the
cached size of invalidated objects. The fix here was to stop
invalidating recorded slots on JSObjects at all and avoid that problem
completely (see https://crrev.com/c/3620274).
Revert #1: Not all size changes go through NotifyObjectLayoutChange, so
https://crrev.com/c/3607992 introduced NotifyObjectSizeChange as a
bottleneck for object size changes/right-trimming. This method is
now used to update the size of invalidated objects.
Bug: v8:12578, chromium:1316289
Change-Id: I0478d04601c0270ddb39419ca6cf98719951eb4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3623542
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80344}
Also manually reformat some files with the clang-format change.
Rolling v8/build: e10cf1a..c8ec41b
Rolling v8/buildtools: c2e4795..113378f
Rolling v8/buildtools/linux64: git_revision:7c8e511229f0fc06f6250367d51156bb6f578258..git_revision:48b013c9d9debc0f5fc1dd71a257b3c38c5acb43
Rolling v8/buildtools/third_party/libc++abi/trunk: 518fd76..c7888dd
Rolling v8/buildtools/third_party/libunwind/trunk: 705543f..d8a4746
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/88422dc..9ba02ee
Rolling v8/third_party/depot_tools: dc8ca44..fccf35c
Rolling v8/third_party/zlib: 32e65ef..961141d
Rolling v8/tools/clang: 3c4a622..75625c6
Rolling v8/tools/luci-go: git_revision:6da0608e4fa8a3c6d1fa4f855485c0038b05bf72..git_revision:2aa3d7e5e8662c5193059a490f07b7d91331933e
Rolling v8/tools/luci-go: git_revision:6da0608e4fa8a3c6d1fa4f855485c0038b05bf72..git_revision:2aa3d7e5e8662c5193059a490f07b7d91331933e
R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: I00a09d42cf91f226c661e97915d5a95fff84b079
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615245
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80343}
