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}
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}
