Adjust WATCHLISTS to only send out updates to those testfiles as part
of notifying oilpan-reviews+v8@.
Change-Id: Ib877f0353ea2b2d1ac06c93d450145dbeb6fcc66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3260517
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77713}
Remove the concept of JobId from LazyCompileDispatcher, and make SFIs
the canonical id for these jobs.
This has several consequences:
* We no longer split enqueing a job and registering a SFI with that
job. We did this previously because we could not allocate SFIs in
the Parser -- now with LocalHeap we can, so we do.
* We remove the separate Job vector, and make the SFI IdentityMap
hold pointers to Jobs directly. This requires a small amount of
extra care to deallocate Jobs when removing them from the map,
but it means not having to allocate new global handles for jobs.
* The SFI is passed into the BackgroundCompileTask instead of the
script, so our task finalization doesn't need the SFI anymore.
* We no longer need to iterate ParallelTasks after compiling (to
register SFIs), so we can get rid of ParallelTasks entirely and
access the dispatcher directly from the parser.
There are a few drive-bys since we're touching this code:
* Jobs are move to have a "state" variable rather than a collection
of bools, for stricter DCHECKing.
* There's no longer a set of "currently running" jobs, since this
was only used to check if a job is running, we can instead inspect
the job's state directly.
* s/LazyCompilerDispatcher/LazyCompileDispatcher/g
Change-Id: I85e4bd6db108f5e8e7fe2e919c548ce45796dd50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259647
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77712}
LayoutDescriptor has been removed some time ago.
Change-Id: I8aa16fcd82be098c9bfd439decef8147514587d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3260515
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77710}
Add CHECK ensuring that the young generation is indeed empty for
pointers updating. This is necessary as otherwise iterating an
object may race with updating a slot in a Map for WasmStruct.
Bug: v8:12185
Change-Id: Id590cf267fedf95d97df2464a638352696ad53db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3260514
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77709}
This reverts commit f9ebad0119.
Reason for revert: suspected root cause of crbug.com/1257806 Additionally, this patch might actually be incorrect as we eagerly evaluate native accessors, which can only happen if the debugger is running.
Original change's description:
> [inspector] Use side-effect free debug evaluate for inherited accessors.
>
> Replace the hard-coded blocklist ("Response.body" and "Request.body") in
> the V8 inspector with proper side-effect free debug evaluate. This is
> otherwise a non-functional change and in particular preserves the
> behavior of reporting accessors as (own) data properties. That will be
> tackled in a follow-up CL.
>
> This CL is possible because with https://crrev.com/c/3056879 Blink now
> properly marks accessors as side-effect free consistently with what the
> V8 inspector had done before.
>
> Doc: http://doc/1gLyyOlssS5zyCSEyybVC-5sp0UnNJj2hBoFyf6ryrTc
> Bug: chromium:829571, chromium:1076820, chromium:1119900
> Change-Id: Idb256accaf4cfb5db5982b3eb06ddcef588be635
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3062573
> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
> Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#76019}
Bug: chromium:829571, chromium:1076820, chromium:1119900, chromium:1257806
Fixed: chromium:1265372
Change-Id: Ia31a3022aaa9ddeae1f01eaa90e345f8bdbb21c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259653
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77708}
The old "gc-safe" implementation to get the off-heap type information
wasn't quite as gc-safe as it needs to be.
Due to parallel compaction, we shouldn't check for forwarding pointers;
instead we should rely on the old location of the Foreign, but make sure
not to look at its Map (which might be a forwarding pointer).
Bug: v8:12185
Change-Id: I4570b00a5300a0d7ed8c042fa21d355373e0e691
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3260513
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77707}
This reverts commit 0446ab7ce1.
Reason for revert: Lots of failures https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/37355/overview
Original change's description:
> [d8] Verify host-defined options
>
> d8 never checked what the actual value of the host-defined options are.
> We now properly very that the host-defined options is a specific object
> so we we don't end up accidentally ignoring a wrong options object.
>
> Drive-by-fix:
> - Convert %AbortJS argument to string
>
> Bug: chromium:1244145
> Change-Id: If0ed128d215682bcf066592418420548b06eb6a1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259655
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77699}
Bug: chromium:1244145
Change-Id: I267f4bdbd8afce81934f4e813dbe1ec09ebdc1ae
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259538
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@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@{#77705}
This runtime function behaves like StoreDataPropertyInLiteral, except it
can throw, since it's also used for defining public class fields. Unlike
the literal use case, class field can end up throwing due to field
initializers doing things like freezing the instance.
Bug: chromium:1264828
Change-Id: I3ea4d15ad9b906c26763f022c8e22b757fa80b6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3252558
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77704}
The goal of the PR is to add to telemetry a metric estimating the space
occupied by the codemap retained by a CpuProfiler and its underlying
CodeObserver.
This change is motivated by the addition of kEagerLogger to CpuProfiler
which when enabled let a CpuProfiler build a CodeMap without an active
session. This metric will help us understand better the space consumed
by a profiler in that scenario and will also help detect memory leaks.
Bug: chromium:1241491
Change-Id: Iadb1ed52b4c1ac70bc554942b4fa795cdf1212f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3224567
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
Cr-Commit-Position: refs/heads/main@{#77703}
Some post-compile flag setting was unnecessary, since those flags
originally came from the SFI they were being set on.
Also, DontOptimizeReason was never actually set, so we can remove it
entirely.
Change-Id: Ic07821fc20ba4e16a2bd8b9e8ac8c1b266aa4067
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3260510
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77702}
This reverts commit 92edf9a1da.
Reason for revert: Breaks mjsunit/es6/proxies-json on GCStress https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/39619/overview
Original change's description:
> [runtime] Optimise paired instance type checks
>
> Clang doesn't optimise over handle derefs. Change the ValueSerializer
> and the JsonStringifier to use InstanceType directly for checks.
> This CL squeezes another 1.5% of JSON.stringify in local benchmarks.
>
> Drive-by-fix:
> - Avoid a few more derefs in the JsonStringifier
> - Make JsonStringifier::SerializeJSArray a bit more readable
>
> Change-Id: I37626a6d92a8d9275611a4e6d1d908f2e0c6d43b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247637
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77697}
Change-Id: I127dd5832b9caceb0d5b74631eede274551405e0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3260511
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77700}
d8 never checked what the actual value of the host-defined options are.
We now properly very that the host-defined options is a specific object
so we we don't end up accidentally ignoring a wrong options object.
Drive-by-fix:
- Convert %AbortJS argument to string
Bug: chromium:1244145
Change-Id: If0ed128d215682bcf066592418420548b06eb6a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259655
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77699}
Clang doesn't optimise over handle derefs. Change the ValueSerializer
and the JsonStringifier to use InstanceType directly for checks.
This CL squeezes another 1.5% of JSON.stringify in local benchmarks.
Drive-by-fix:
- Avoid a few more derefs in the JsonStringifier
- Make JsonStringifier::SerializeJSArray a bit more readable
Change-Id: I37626a6d92a8d9275611a4e6d1d908f2e0c6d43b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247637
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77697}
Currently, the safepoint is last call instruction's return address on
mips and loongarch64 platform. But in `CallCFunction`, there are some
other instructions after calling, which leading to a wrong safepoint
record on mips and loongarch64.
So I record the pc for safepoint at the end of `CallCFunction`
function, and change `last_call_pc_` to `pc_for_safepoint_`.
Besides, commit 48b2b89176 introduced
a typo on loong64 platform, I also fixed it in this CL.
Change-Id: Ia3ea77ae2f6f1c8c604e35f420a7632a78c9725a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258875
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77694}
Currently, in the following struct
struct LayoutObject : GarbageCollected<>, MixinA, MixinB {};
the subobject that corresponds to the first base GarbageCollected<>
always takes up some space (one word). The empty-base-optimization
doesn't happen because the second base (MixinA) has the same subobject
as the first base (GarbageCollected), which is the most parent class
GarbageCollectedBase. The compiler can't "merge" them because it must
guarantee that distinct objects of the same type have distinct
addresses.
The attribute [[no_unique_address]] doesn't work for base classes,
unfortunately (but is a good idea for a Standard proposal). As a
solution, the CL simply removes GarbageCollectedBase.
Bug: chromium:1260797
Change-Id: I415b10a5fbcebce3d6ee97b8870ea9ae90f383a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259654
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77693}
When a GC happens during context deserialization,
NativeContext::retained_maps might be uninitialized and not store a
WeakArrayList but Smi 0.
Bug: v8:12198
Change-Id: I03c1dfaa013c47907af67bb13b9277d67ca5ffae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259662
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77692}
This reverts commit a3480b5551.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug%20-%20header%20includes/22234/overview
Original change's description:
> Reland "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants"
>
> This is a reland of 7366f6e204
>
> The test that failed after the initial commit was just flaky and has
> been fixed; see https://bugs.chromium.org/p/v8/issues/detail?id=12341
>
> Original change's description:
> > [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants
> >
> > Torque currently generates constants like kStartOfWeakFieldsOffset and
> > kEndOfStrongFieldsOffset, which can be used when writing custom
> > BodyDescriptors. However, these offsets have some potentially confusing
> > behaviors:
> >
> > * They don't take inheritance into account and describe only the fields
> > defined by the current class itself, so there might be (for example)
> > strong fields before kStartOfStrongFieldsOffset if they were defined
> > by a superclass.
> > * kStartOfWeakFieldsOffset points to the first field defined in Torque
> > using the keyword `weak`, which indicates fields with *custom*
> > weakness semantics (those that should be visited with
> > IterateCustomWeakPointers), not those that may contain standard weak
> > pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
> > like to also rename `weak` to `@customWeak`.)
> >
> > Given that these constants have very low usage and somewhat bizarre
> > semantics, I propose that we remove them. This change does so, and
> > updates the existing usages to either define the required constants
> > directly in C++ or not use them. I know that defining these constants in
> > C++ is more brittle, but I think that brittle and clear is better than
> > automatic and incomprehensible.
> >
> > Bug: v8:7793
> > Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> > Cr-Commit-Position: refs/heads/main@{#77411}
>
> Bug: v8:7793
> Change-Id: Iefdd4014ce4b85b48c19ead79a0316774a5ecd45
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258082
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#77688}
Bug: v8:7793
Change-Id: I7b9667268901b7aef85a95832d40860056e61050
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259656
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77689}
This is a reland of 7366f6e204
The test that failed after the initial commit was just flaky and has
been fixed; see https://bugs.chromium.org/p/v8/issues/detail?id=12341
Original change's description:
> [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants
>
> Torque currently generates constants like kStartOfWeakFieldsOffset and
> kEndOfStrongFieldsOffset, which can be used when writing custom
> BodyDescriptors. However, these offsets have some potentially confusing
> behaviors:
>
> * They don't take inheritance into account and describe only the fields
> defined by the current class itself, so there might be (for example)
> strong fields before kStartOfStrongFieldsOffset if they were defined
> by a superclass.
> * kStartOfWeakFieldsOffset points to the first field defined in Torque
> using the keyword `weak`, which indicates fields with *custom*
> weakness semantics (those that should be visited with
> IterateCustomWeakPointers), not those that may contain standard weak
> pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
> like to also rename `weak` to `@customWeak`.)
>
> Given that these constants have very low usage and somewhat bizarre
> semantics, I propose that we remove them. This change does so, and
> updates the existing usages to either define the required constants
> directly in C++ or not use them. I know that defining these constants in
> C++ is more brittle, but I think that brittle and clear is better than
> automatic and incomprehensible.
>
> Bug: v8:7793
> Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#77411}
Bug: v8:7793
Change-Id: Iefdd4014ce4b85b48c19ead79a0316774a5ecd45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258082
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77688}
We only expect the "wasm_exception_values_symbol" property to be a fixed
array if the property actually exists. If the property is not found,
JSReceiver::GetProperty returns "undefined", so skip the check in this
case.
R=clemensb@chromium.org
Bug: chromium:1262582
Change-Id: I28d7891064bdd7632ff1a4c94ba021163401fd88
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3244416
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77685}
If index > JSObject::kMaxElementIndex, we have to perform a prototype
chain lookup for a named property. The corresponding check was missing
for string receivers.
Fixed: chromium:1265043
Change-Id: Ibccd058a4bd108eeee235762bea0bc4163aaa0b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257704
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77683}
`UseScratchRegisterScope` should be used in a block scope, to avoid keeping the
scratch register in use for longer than it's needed. Spotted when experimenting
with the `v8_enable_heap_sandbox` and `v8_enable_external_code_space` flags.
Change-Id: I34330f3e4dbd114aa75efb0ebdcf557f0bd45f11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256997
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/main@{#77679}
In order to avoid some of the unnecessary Code <-> CodeDataContainer
conversions in builtins we need to be able to embed CodeDataContainer
references to builtins.
This CL makes it possible by introducing a table of builtins' CDCs.
Eventually, usages of the builtins table containing Code objects will
be replaced by usages of this table.
Bug: v8:11880
Change-Id: Iffffd1507d5c7b38af34c42071a4577a8d18e8eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257710
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77678}
The runtime function 'WasmIsValidRefValue' can be called from C-API and
JS wrappers and needs to be passed an instance. Therefore, we always
have to define an instance node, even when it is just undefined.
See also https://chromium-review.googlesource.com/c/v8/v8/+/3236719.
Bug: v8:11510, chromium:1266080
Change-Id: Ib9712fe3a3880db8656ee4882bec0ae7635cc60f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257708
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77677}
This is a reland of 35a6eeecfa
Reland fixes:
* Add a SharedFunctionInfo::CopyFrom to encapsulate updating the SFI
from the placeholder. This now includes copying scope_info (which
wasn't included in the original CL and caused some of the issues)
* Make sure that LocalHandleScope is initialised only inside of
UnparkedScope (fixed TSAN issues)
* Clean-up: Don't add `script_` to ParseInfo, but instead pass it
separately to Parser. Eventually we'd ideally get rid of ParseInfo
entirely (splitting it into input and output) so let's not add more
fields to it. Reverts changing CreateScript to InitializeScript.
Original change's description:
> [off-thread] Allow off-thread top-level IIFE finalization
>
> Allow off-thread finalization for parallel compile tasks (i.e. for top-
> level IIFEs).
>
> This allows us to merge the code paths in BackgroundCompileTask, and
> re-enable the compiler dispatcher tests under the off-thread
> finalization flag. Indeed, we can simplify further and get rid of that
> flag entirely (it has been on-by-default for several releases now).
>
> Change-Id: I54f361997d651667fa813ec09790a6aab4d26774
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226780
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77615}
Change-Id: If1a5b14900aa6753561e34e972a293be0be9a07d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256692
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77676}
.. as a custom data structure with questionable value.
Also: a few drive-by refactors.
Change-Id: I74957b70c4357795dc46ef5520d58b6a78be31b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3240823
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77674}
Unfortunately, CharacterRanges may use 0x10ffff as a marker value
signifying 'highest possible code unit' irrespective of whether the
regexp instance has the unicode flag or not. This value makes it
through RegExpCharacterClass::ToNode unmodified (since no surrogate
desugaring takes place without /u). Correctly mask out the 0xffff
value for purposes of building our uint16_t range array.
Note: It'd be better to never introduce 0x10ffff in the first place,
but given the irregexp pipeline's lack of hackability I hesitate to
change this - we are sure to rely on it implicitly in other spots.
Drive-by: Refactors.
Fixed: chromium:1264508
Bug: v8:11069
Change-Id: Ib3c5780e91f682f1a6d15f26eb4cf03636d93c25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256549
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77673}
It is easy to miss that a LocalHandleScope can only be created when
the current thread is in the running state and not parked. Add a DCHECK
for this, such that we don't need to rely on TSAN for finding such
issues.
Bug: v8:12357
Change-Id: I1f2f9b1fdf05814009f2edccf192afbb1caf6baf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257705
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77672}
NewJSObjectWithNullProto has use cases outside of the debugger. We
previously changed it to create dictionary mode objects, which affects
the performance of non-debugger use cases. This change partially
reverts that change by differentiating between use cases.
Fixed: chromium:1266160
Change-Id: I875073bdc062cf187ef24da62324f743169d2e29
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257706
Auto-Submit: Yang Guo <yangguo@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77671}
With LocalHeaps multiple threads may now access the heap. We now need
to bring background threads to a safepoint and make all LABs iterable
in order to be able to safely iterate the heap.
Bug: v8:12338
Change-Id: Ia39f3bf7ac13ba405c86ee2f0048c600ce36c2d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256690
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77670}
Port 4de20cb1de
Change-Id: I8801bbcf9647c1abcb9cc5fb41720009e002d153
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257964
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#77667}
This CL makes sure the offset is calculated correctly to be
the return address from a C Function. Checking the size
of generated code is also fixed to take into account the extra
instruction we have from LoadPC.
Change-Id: I585c11efbe4342bc5a0d3068683b54cb563a3bc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257206
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#77666}
- Fix definition and declaration of noexcept methods not matching
- Disable test using deprecated APIs. Only having clang coverage is
okay here.
Change-Id: I412d0b0087b2858fb72b0365b94b82ebc13462de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256693
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77665}
This improves the performance of initializing instances with
private methods by 5-6x and makes it on par with initializing
instances with only public methods.
Drive-by: remove the obsolete AddPrivateField runtime function
along with the AddPrivateBrand function.
Bug: v8:10793, v8:12355
Change-Id: Ic0896adb2102db7790f955fecbdd22f61ab2e7ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256999
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77664}
