Rolling v8/build: 843261b..cf385c0
Rolling v8/buildtools: 92ea83b..9e95466
Rolling v8/buildtools/third_party/libc++/trunk: e73c465..d128f2b
Rolling v8/third_party/depot_tools: 421c4fe..18bdadc
Rolling v8/third_party/fuchsia-sdk/sdk: version:9.20220916.1.1..version:9.20220917.2.1
Rolling v8/tools/clang: c3b78bc..b118dfdR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: I0474c3176189c9245220bf5682a75e78cb20d8da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3903332
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#83285}
Rolling v8/build: b001130..843261b
Rolling v8/buildtools: 813d569..92ea83b
Rolling v8/buildtools/linux64: git_revision:e70d8c3d5620bc0ddcbad23a36b1b26f815ca90a..git_revision:cc28efe62ef0c2fb32455f414a29c4a55bb7fbc4
Rolling v8/buildtools/third_party/libc++/trunk: e2f63a1..e73c465
Rolling v8/buildtools/third_party/libunwind/trunk: 60a480e..77b82eb
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/c067655..fcf15b9
Rolling v8/third_party/depot_tools: dca14bc..421c4fe
Rolling v8/third_party/fuchsia-sdk/sdk: version:9.20220915.2.1..version:9.20220916.1.1
Rolling v8/third_party/zlib: 7d7ed92..8f22e90
Rolling v8/tools/luci-go: git_revision:c93fd3c5ebdc3999eea86a7623dbd1ed4b40bc78..git_revision:78063b01b53dd33a541938207b785cc86d34be37
Rolling v8/tools/luci-go: git_revision:c93fd3c5ebdc3999eea86a7623dbd1ed4b40bc78..git_revision:78063b01b53dd33a541938207b785cc86d34be37
R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: Iab1835ab4d720c4499485def6680f8cbed20fa90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3901693
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#83284}
This CL unifies the fields for shared spaces for both the shared
isolate and the shared space isolate-approach. This allows to mostly
avoid separate code paths for both implementations.
While this CL already sets up everything needed for allocation with
--shared-space, allocation isn't fully working with this CL due to
other remaining issues.
Bug: v8:13267
Change-Id: Icdb40ed7045e33e6acbb97d3838fa374e6c24a2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3892786
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83280}
Finalizing sweeping can be beneficial to truly end a GC cylce. We
should only finalize in `FinishIfOutOfWork()` though if that would not
introduce any jank. Limit the amount of executing finalizers in that
scenario.
Bug: v8:13294
Change-Id: I0237f6b6017d444c457923d83e85147c58586445
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3902222
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83279}
In order to support a larger heap cage (8GB, 16GB), the cage offset
will take up more than 32 bits. As a consequence, for 8GB cages, the
least significant bit of the cage offset will overlap with the most
significant bit of the tagged offset. To avoid this, allocations need
to be aligned to 8 or 16 bytes to free up one or two bits from the
offset.
The allocation top is kept properly aligned without adding fillers in
the newly created gaps, by aligning allocation sizes to 8 bytes.
Bug: v8:13070
Change-Id: I169b51e583d7a4be61d2a6c6060fcf74b410703c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3877147
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Teo Dutu <teodutu@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83277}
In multiple counters we have peaks in the 0 microseconds and 1000
microseconds bucket, most probably coming from clients with a
low-resolution clock. Exclude those to get more precise timings.
R=jkummerow@chromium.org
Change-Id: I9b8377354920db4d0070198f440b57a7e86dc7bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3902221
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83276}
We move js-to-wasm wrappers to a WeakFixedArray in the isolate,
indexed by their canonical type index. This ensures that they are
reused across instances, and get GC'd when no longer needed.
We also remove eager compilation of wrappers.
This CL fixes some issues that were caused by out-of-bounds accesses
to wrapper arrays attached to module objects.
Bug: chromium:1363859, chromium:1363895
Change-Id: Idec0925e775f51fdfa7cd380379b0d1798295a0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3893860
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83275}
Looks like we hammered on the regalloc hard enough that this works again
🥳
Bug: v8:7700
Change-Id: I4f02417e069e3a6d89ca0c8c43ba165a502150e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899302
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@{#83272}
Avoid the deprecated FLAG_* syntax, access flag values via the
{v8_flags} struct instead.
R=jkummerow@chromium.org
Bug: v8:12887
Change-Id: Ia17d668b3ddcbcb7a35388231aa5d80e8e5b419b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899122
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83270}
We only complete sweeping when the young generation GC is enabled.
Change-Id: I915acce35d6ba16716c2c4ee4130f99af0744f83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3900377
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83269}
Align slow path allocation with V8 in that:
1. Try to refill from the free list.
2. Perform limited sweeping of a space if necessary and retry the free
list.
3. Try to expand the space.
4. Perform full sweeping of a space if necessary and retry the free
list.
5. Finish sweeping fully as we would anyways do a GC at this point.
6. Retry the free list again
7. Try expanding again as finishing sweeping may have freed up pages.
Specifically, this adresses a performance problem where we would fully
sweep the whole heap, possibly causing 100ms of jank on allocation. In
such cases the new approach maintains performance and stays fast at the
expense of using more memory.
Allocations usually find memory in 1.-3. Steps 4.-7. are slow paths
that are definitely expensive but prevent failing with OOM.
Bug: v8:13294
Change-Id: I56133fa4cbbc74f8abcdec49c7e10125c2dbc3e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899260
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83268}
Avoid the deprecated FLAG_* syntax, access flag values via the
{v8_flags} struct instead.
R=saelo@chromium.org
Bug: v8:12887
Change-Id: I7e41e1952958936c32fec501b8348fac0538cd71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899269
Reviewed-by: Samuel Groß <saelo@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83265}
Avoid the deprecated FLAG_* syntax, access flag values via the
{v8_flags} struct instead.
R=ishell@chromium.org
Bug: v8:12887
Change-Id: I2ef25bc50fdf12f0149f2cdfce7102f2cc0f25d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899196
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83261}
Isolate::shared_isolate() was used in many locations to check for the
shared heap feature. Now that we also have shared_space_isolate()
checking shared_isolate() isn't sufficient anymore.
This CL replaces many invocations of this method with either
has_shared_heap() or shared_heap_isolate(). These methods work for
both shared_isolate() and shared_space_isolate(). As soon as we remove
the shared isolate we can remove them again.
Bug: v8:13267
Change-Id: I68a3588aca2a12e204450c2b99635dd158d12111
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899316
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83260}
All --stress-* flags are now automatically tested. This also removes
a superfluous option that was never changed. The default value is
now inlined.
No-Try: true
Bug: v8:13113
Change-Id: If7428b383ed01ff36a93f618badababfc448db26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899259
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83258}
Before adding serialization of tiering information, refactor the
existing code to use a {ProfileGenerator} class. This makes it easier to
add new methods that can use all existing fields (instead of having new
functions that need a lot of parameters).
R=jkummerow@chromium.org
Bug: v8:13209
Change-Id: I0946cb1d507fde9e6d680ad588ba963c539d1d0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899301
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83257}
The number of feedback vector slots is currently stored in the
{WasmFunction}, returned in the {WasmCompilationResult}, and implicitly
stored as the size of the {call_targets} vector in
{FunctionTypeFeedback}.
This CL uses the latter as the source of truth, encapsulated in a new
{NumFeedbackSlots} function. This can be updated when adding new kinds
of feedback that need additional slots.
For now, the implementation of {NumFeedbackSlots} requires taking a
mutex, which we can hopefully avoid when productionizing speculative
inlining. We also take the mutex on every Liftoff compilation, which
adds synchronization between concurrent compilation which we previously
tried very hard to avoid (because it introduced significant overhead for
eager compilation).
As a nice side-effect, this CL reduces the per-function overhead by 8
bytes, independent of enabled features.
R=jkummerow@chromium.org
Bug: v8:13209
Change-Id: I2fe5f7fe73154328032a3f0961e88d068c5d07ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899299
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83253}
This is a reland of commit 10756bea83
The reland is mostly unchanged except for changing the name for
the shared large object space. The name should use the same style
as other large object spaces.
The main reason for reverting was fixed in
https://crrev.com/c/3894303.
Original change's description:
> [heap] Add shared spaces for --shared-space
>
> This CL adds shared spaces for regular and large objects in the shared
> space isolate. Spaces aren't used for allocation yet.
>
> Bug: v8:13267
> Change-Id: If508144530f4c9a1b3c0567570165955b64cc200
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3876824
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83178}
Bug: v8:13267
Change-Id: I3de586c1e141fb5f7693e2d6972db251b4a4f434
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3892950
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83252}
We can't freely concatenate strings in the background because they
could be mutated by the main thread (eg, flattened, internalized,
externalized...).
So, when there is a JSAdd between 2 constant strings, we first checked
if they are "safe" (= internalized, I think), and if so, we
concatenate them at compile time. If they are "unsafe", then we don't.
It turns out that this wasn't an issue with delayed constant strings,
since the content of the strings were never accessed: the actual
concatenations were done on the main thread, where it's safe to do.
This CL fixes that for most cases:
- if the strings really cannot be read from the background, but the
length of their concatenation is more than ConsString::kMinLength,
then we create a ConsString.
- I added a set to record which strings we created in the turbofan:
those strings can safely be accessed from turbofan regardless of
their type.
The only case where delayed constant strings could be a bit better is
when there is a concatenation of 2 small non-internalized string,
because right now, we wouldn't fold it. Still, it should happen very
rarely, if ever.
Bug: chromium:1359941
Change-Id: I651b834273de89f1e3c60654094a4606dd9c62f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3891252
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83251}
This moves the existing PGO code to a separate cc file with a separate
header. As the implementation will be further extended in follow-up CLs,
it's better to have it separated.
R=jkummerow@chromium.org
Bug: v8:13209
Change-Id: I7b7b5bf9c8d3d542dae734f3874499dccee152a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899321
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83250}
Resolve a TODO to remove cached template objects from the template cache
which have a cleared weak pointer to the template object. Requires a
little bit of awkward code to handle the "head is dead" case, but OTOH
the implementation cleans up the second Lookup of the head.
Bug: v8:13190
Change-Id: I31a8d8ab77e04c8496a2cacb6154f2ee84d6a795
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899257
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83249}
The cached template object weakmap shouldn't be updated when we update
an existing cached template object, because this update can truncate the
linked list of cached template objects.
Bug: v8:13190
Change-Id: Icea61fcbd5c05d4293a884d1872523ddcdfc3323
Fixed: chromium:1364429, chromium:1364471
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899256
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83248}
This is a reland of commit 0a1f0e335e
Changes since revert:
- Deferred label for loading from forwarding table.
- Check if hash is computed instead of checking if it is a forwarding index.
- Retreive hash from forwarding table only if hash is assumed to be computed.
Original change's description:
> [strings] Fix raw hash lookup for forwarded strings
>
> Raw hashes may need to be looked up via the forwarding table when
> internalized strings are forwarded to external resources. Notably, the
> megamorphic ICs were not correctly fetching the raw hash.
>
> Bug: v8:12007
> Change-Id: Ibbc75de57e707788f544fbd1a0f8f0041350e29d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3885379
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83115}
Bug: v8:12007
Change-Id: Ia88ed51a49c62170bc960b8f69673bb1e59a6009
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3888057
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83246}
This reverts commit 80fb281561.
Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1364400
Original change's description:
> [turbofan] Rematerialize BigInt64 in deopt
>
> This CL introduces two MachineTypes - SignedBigInt64 and UnsignedBigInt64, which are represented as Word64 but will be rematerialized to BigInt in deoptimization. This will avoid unnecessary conversions for BigInt64s when they are passed to StateValues.
>
> Bug: v8:9407
> Change-Id: I65fdee3e028ed8f9920b1c20ff78993c7784de48
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3858238
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Qifan Pan <panq@google.com>
> Cr-Commit-Position: refs/heads/main@{#83230}
Bug: v8:9407
Change-Id: I77d278ce302621db03b787318641709780348cc8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3901814
Auto-Submit: Nico Hartmann <nicohartmann@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@{#83245}
A recent refactoring changed the behavior of dropping/keeping
results after test execution. The numfuzz loop has previously
treated all results as analysis results, as it expected that others
are dropped. After keeping all results, the second round invalidated
the analysis results and the test loop stopped early.
We now add an additional safeguard that ensures the received result
is indeed associated with an analysis run and do not depend anymore
on result presence/absence.
This also adds all analysis-based instances to the test cases.
No-Try: true
Bug: v8:13295
Change-Id: Ic1ede904d279a0c2b318ec997e7c77542dbc75bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3901812
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83244}
This improves the num-fuzzer system test. Previously, the test
didn't actually start up the main functionality of num-fuzz and
executed 0 tests. Now several of the production fuzzers are used to
run fake test cases. The overall timeout signal, used to
stop numfuzz, is mocked with a counter. The observer signals via the
event method that would have caused the hang fixed in:
https://crrev.com/c/3891373
No-Try: true
Bug: v8:13113
Change-Id: I47d17c1fa2099474079acaad5640228d8c454eb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3893807
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83243}
Do it conditionally only when young-gen is enabled.
Change-Id: I1bd8ed49302b9e2aef0a60ed7831de9ec1cbe276
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899308
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83241}
Myers algorithm for live edit diffing has been enabled since 10.6
without any reported problems, so we can safely remove the dynamic
programming approach with 10.8.
R=kimanh@chromium.org
Bug: chromium:1205288
Change-Id: I95c26c11e949b8c36a0b6abd54859b3936933e9d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3901811
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83240}
Rolling v8/build: ccee528..b001130
Rolling v8/buildtools: 040e851..813d569
Rolling v8/buildtools/linux64: git_revision:fff29c1b3f9703ea449f720fe70fa73575ef24e5..git_revision:e70d8c3d5620bc0ddcbad23a36b1b26f815ca90a
Rolling v8/buildtools/third_party/libc++/trunk: c1e647c..e2f63a1
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/0d1854a..c067655
Rolling v8/third_party/depot_tools: 5e4d749..dca14bc
Rolling v8/third_party/fuchsia-sdk/sdk: version:9.20220914.1.1..version:9.20220915.2.1
Rolling v8/third_party/zlib: f48cb14..7d7ed92
Rolling v8/tools/clang: 12149f2..c3b78bcR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: Ie381cd91ebf11d348beed4fdcc099292aa7ef3b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3900398
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#83239}
Now that we have all useful flags on the API side, use to them.
Bug: chromium:1056170
Change-Id: Ia849b0925a2b2c10ace30b6c2b6871bd3572da31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899306
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83238}
This reverts commit 4444874cdf.
Reason for revert: CHECK failure under UBSan
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan%20-%20builder/5103/overview
Original change's description:
> [v8] Use |AllocateAtLeast| for resizing v8 zones.
>
> This is part of an ongoing effort to reduce fragmentation in Chrome. Partition alloc shows v8 zones are a large user of memory in Renderer processes, and that there is fragmentation from these allocations. This CL will reduce this fragmentation by allowing v8 to use all allocated memory for its zones.
>
> Bug: v8:13193, chromium:1238858
> Change-Id: Ibeac8bdba9d0e7ff66b14a3dde10e7c87d3cf953
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3889361
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Thiabaud Engelbrecht <thiabaud@google.com>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83235}
Bug: v8:13193, chromium:1238858
Change-Id: I03c8c1ad7bb1cd20770323bffe1c42a4be47c454
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3900814
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83237}
Need to reset tzi_xxx and calendar_xxx in parser state if the
post-condition of CalendarName and TimeZoneIdentifier is not met.
Bug: v8:11544
Change-Id: If2df6c8fc8cf2418ddd5443abab02066d423a0c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3893554
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83236}
