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}
I'm in the process of evaluating impact of v8 snapshot and
would like to understand the amount of time spend decompressing.
BUG=chromium:1257321
TEST=none
Change-Id: I122a2151e48f61db3352da56763e3e66f7415efe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256006
Commit-Queue: Scott Violet <sky@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77661}
Add support for non-nullable reference types.
Refactor the GetValueType function. Emit a meaningful
initializer for every ref type in globals instead of an
empty one. Avoid the non-nullable recursive type by only
allowing indices that are strictly less than the current index.
Bug: v8:11954
Change-Id: Id1a405525080de7eb9dbbd4f2b8aea5f05684665
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3251171
Commit-Queue: Maria Tîmbur <mtimbur@google.com>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77659}
Explicitly specify the enum base type for Flags enums generated
from Torque bitfield structs. Before, this was implicitly a signed
integer type. This caused a recent gcc compile issue with signed
and unsigned comparisons triggered by
https://chromium-review.googlesource.com/c/v8/v8/+/3251177
Bug: v8:7793
Change-Id: Iceb3c8632cfc95766b5e6ce7fae47cf5d002b9f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3253358
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77658}
Apply a "modulo" (i32.rem_s) operator to the array size before
allocating the array. The unbounded array allocations frequently lead to
out-of-memory crashes in the fuzzer.
R=manoskouk@chromium.org
Bug: chromium:1238063, chromium:1258319
Change-Id: Ie344f783323294c711d75b6e004ff2dca4da5923
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256548
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77657}
Data race access to chunk_map_. The main thread can read the map
while the background thread (concurrent SP compiler) adds a new page
to the map.
Bug: v8:12054
Change-Id: Ie7c596f3d3aeb4dca9cc6f41ed16f39dcafc7871
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256547
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77654}
Currently it is not possible to run samples on arm architecture
I faced the issue on Macbook Pro M1
Running sample codes is crucial for getting started with the project
R=tandrii@chromium.org
Bug: None
Change-Id: Ie3ed52e68d1f7193217110d43545971c714202c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3251026
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77653}
When a Promise-Reject handler throws an unhandled exception, we should
use that promise's context for reporting the exception to the runtime.
This avoids a null-pointer deref.
Fixed: chromium:1263994
Change-Id: I3792a1884af4a83991249d612caf15588ea77dad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250912
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77652}
This CL adds a minor change to the arm/arm64 simulators to support up to
20 arguments in a C function call. This change is necessary for an
upcoming CL which adds float support to the simulator and tests with
more than 20 arguments, see
https://chromium-review.googlesource.com/c/v8/v8/+/3060486
Bug: chromium:1052746
Change-Id: I60ae603c96554525d28f1cd248d7766f86c9cc3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256785
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77651}
When materializing a scope object, we previously assumed that we will
not have any name collisions. This is not correct e.g. when eval
introduces an aliased local variable.
This CL resolves this wrong assumption. The test case should not crash.
It however fails as there is a bug in how debug-evaluate should resolve
variables defined in eval.
R=verwaest@chromium.org
Fixed: chromium:1240962
Bug: chromium:1264852
Change-Id: I0e41e7905589735e25eff221376d09997ea99117
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250911
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@{#77649}
After https://crrev.com/c/3247035 compilation with gcc may fail
with the following error:
```
error: comparison between 'enum v8::internal::
compiler::BitsetType::<unnamed>' and 'enum v8::internal::
TurbofanTypeBits::Flag'
```
Change-Id: I5edf28e335483be66ae46e4359e0a4dc83341adf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3255303
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#77647}
Since early regexp errors were implemented in
crrev.com/a56874d3eb5cff9f8f04f899ac45d0d2ef88ab4d, the JS parser
calls into the regexp parser to validate the regexp literal syntax.
For these calls, the JS parser passes its Zone to the regexp parser.
This means that scripts with multiple regexp literals are all parsed
using the same Zone memory. Very large scripts with many (think
hundreds of thousands) regexp literals may thus run out of memory
whereas previously they would parse and run successfully.
This CL fixes the OOMs by resetting the state of the JS parser Zone
around regexp parser calls. We introduce a new ZoneScope class,
similar to HandleScope, which controls the lifetime of zone objects
allocated within its scope. In other words:
{
ZoneScope zone_scope(zone); // Store zone state S.
// ... Allocate objects O in zone.
// zone is now in state S'.
}
// zone_scope goes out of scope, reset zone to state S. Objects O
// are freed and no longer usable.
Fixed: chromium:1264014
Bug: v8:896
Change-Id: I3e7ac36f25a9d6c4eda2460bd1bea9814685e89b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256783
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77646}
In stress runs a GC may kick in before assertOptimized() is called
on the optimized function, causing it to deoptimize and the test
would fail even if the function is optimized as expected.
Adding --no-stress-flush-code --no-flush-bytecode fixes the timing
issue.
Bug: v8:12332
Change-Id: If43c2a06e84c0e3b5e21f7bde160340a0fc742f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3237326
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#77645}
Fixes `buildifier` warning, since the alias has the same name
as the icu/noicu/d8 targets.
The alias was used in the CI bot, but this is no longer the case.
No-Try: true
Change-Id: Ie8e9b6b2d8510c78982ed4c6845b51a4d4378106
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3253356
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77644}
This patch refactors the ClassFields benchmarks and makes the results
detection work properly. Previously the errors weren't caught since
the ClassFields benchmarks don't get run in the perf_integration
step in the CI.
- Instead of putting different configs (single/multiple fields, type
of fields, etc.)in the JSON configuration, we now group the related
benchmarks into the same script and run the different configurations
in the scripts directly. Only the optimization status is now
controlled in JSON. All the class fields definition benchmarks are
merged into initialize-class.js.
- Update the number of local iterations of evaluate-class.js to 100
(similar to most of other benchmarks) to keep the time spent on
this benchmark similar to that of other benchmarks.
In addition, copy the configs to JSTests3 so that the benchmarks gets
run by the perf_integration step and we can see the graphs on
http://chromeperf.appspot.com/report. These can be removed
when the ClassFields benchmark results are generated there too.
Bug: v8:10793, v8:9888
Change-Id: I4e677bdc7b582650f39cf6e9ec02775c57fd04ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226550
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77640}
