Cppgc reports used bytes statistics to CppHeap. CppHeap should forward
the stats to v8. However, if we are not allowed to trigger a GC, CppHeap
will cache the stats until the reporting.
On GC finalization, CppHeap resets v8's counters to the current marked
bytes counter.
If the last reported stats before GC finalization are cached, CppHeap
doesn't clear the cache on GC finalization. On the next stats reporting,
CppHeap will report the cached values. If the cache is a decrease that
is larger than the current marked bytes, a DCHECK in
LocalEmbedderHeapTracer::DecreaseAllocatedSize will fail.
Bug: chromium:1056170
Change-Id: I47933abc3e5f5c4a91454e0ec03adde5cf61d8fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056970
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75986}
The test makes sure that JSON parsing doesn't stack overflow if given a
deeply nested JSON object. This deep nesting makes the test slow, so we
can test ~the same thing by lowering both the nesting and the stack
size.
Bug: v8:12029
Change-Id: I689ffc1b9db167a1cf1de93beeb09c89e03264a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059685
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75976}
The test currently fails on machines with sparkplug enabled:
```
Flag --sparkplug: value implied by --jitless conflicts
with explicit specification
```
And passes on platform without sparkplug.
Bug: chromium:1233401
Change-Id: Ia0277f8d356e34efb611ca9960c11ec78b9b94ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3058300
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75970}
R=leszeks@chromium.org
Bug: chromium:1233401
Change-Id: Ieaf7513d2dbd9bc84a996defbf0a929d35befa36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059082
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Auto-Submit: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75967}
We add new alternative "new_object" in order to
emit new struct and array types. We check whether
heaptype is struct or array type so we could emit
"NewDefault" or "NewWithRtt". The additional methods
(IsArray/StructType, GetArray/StructType) was added to WasmModuleBuilder.
Bug: v8:11954
Change-Id: I7a0e73edfbaa49beb1efd60b0f1b9916dc50df22
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056459
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Rakhim Khismet <khismet@google.com>
Cr-Commit-Position: refs/heads/master@{#75966}
Previously we do not tier down from baseline to interpreter, which
breaks per-bytecode side effect checks (to check whether e.g. we are
mutating a temporary object, which is not considered a side effect).
R=leszeks@chromium.org
Bug: chromium:1233401
Change-Id: Ie08b5352aa4c124421b4c9abce18326938bbc822
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056981
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75963}
Previously we'd report all property edges with symbol names as <symbol>,
which was not very useful, especially with private class fields now
seeing more adoption.
Fixed: chromium:1232467
Change-Id: I53cf0811c4b83d016b988b687c6decbddd3c2fdd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055309
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75962}
Found these when compiling the arm64 simulator for MSan (Release) and
ASan (Debug and Release). Depending on the exact configuration (and
compiler), different functions will get inlined and different symbols
need to be available at link time.
1) Since GetRecoveredTrapCount is used in a unittest, it needs to be
exported.
2) The thread-local g_thread_in_wasm_code cannot be exported on
Windows, hence it cannot (safely) be used in unit tests. Use the
{GetThreadInWasmThreadLocalAddress} function instead, which will
return the address of that thread-local variable.
R=ahaas@chromium.org, mseaborn@chromium.org
Bug: v8:11955
Change-Id: I118f60c1580a8362f8232541576a1c41da7042bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049077
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75960}
ComputeMinObjectSlack is called concurrently from background threads
(when --concurrent-inlining) and must therefore be thread-safe.
This CL adds a compiler-specific thread-safe variant
of ComputeMinObjectSlack in addition to the plain old non-thread-safe
one. Thread-safety is achieved through locking: on the bg thread, a
shared lock when traversing transitions, and on the main thread, an
additional exclusive critical section when overwriting prototype
transitions.
Tbr: leszeks@chromium.org
Bug: v8:7790,v8:12010,chromium:1231901
Change-Id: If5af83df1ab896b22477921449fb5ba4c8d3e8a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3045342
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75949}
It was previously only passed to compilation units in src/bigint/,
but inconsistencies arise when it's not passed to other compilation
units that #include src/bigint/bigint.h.
Fixed: chromium:1233397
Change-Id: Idb310d8c13bad12766699086574aa2c3869eb56c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056452
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75941}
This reverts commit 67960ba110.
Reason for revert:
This has been properly fixed by https://crrev.com/c/3053740.
Now dcheck_always_on already defaults to false for subprojects
like V8 and no other switch is required. The switch didn't fully
work anyways due to https://crbug.com/1231890.
Original change's description:
> Reland "[build] Add V8-specific dcheck_always_on"
>
> This is a reland of cecc666f4d
>
> Depends on:
> https://crrev.com/c/3043611
>
> Original change's description:
> > [build] Add V8-specific dcheck_always_on
> >
> > This makes the V8 dcheck control independent of Chromium's and
> > prepares switching Chromium's default behavior without affecting V8
> > developers or builders.
> >
> > Preparation for: https://crrev.com/c/2893204
> >
> > Bug: chromium:1225701
> > Change-Id: I520b96019b04196f4420716ff3500ebd6c21666f
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038528
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#75827}
>
> Bug: chromium:1225701
> Change-Id: I56568b78592addba01793d2d14f768c9ee10103d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041670
> Reviewed-by: Liviu Rau <liviurau@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75839}
Bug: chromium:1225701, chromium:1231890
Change-Id: I7e27f5774d8e162977f30f685da4b15dadcc1084
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055294
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75935}
The implementation came in with
https://chromium-review.googlesource.com/758999.
This feature was never enabled by default, is not used anywhere, and
is not on any standardization path.
Bug: v8:10953
Change-Id: Ia2b0a556c1fb504a4cd05bdfa9f0a9c5be608d26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3053589
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75934}
It is very unlikely that atomic.wait does anything useful in the fuzzer,
and will most likely just timeout the fuzzer. That's why it's better to
just disallow atomic.wait on the fuzzer.
R=thibaudm@chromium.org
Bug: chromium:1229074
Change-Id: I57aaff013964fa4c0e6ab411789e53a9013cabd2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3053584
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75920}
In inlined-call-polymorphic we need value numbering phase to
deduce that TurbofanStaticAssert is always true. Turboprop doesn't
enable this phase. So use %OptimizeFunctionTopTier so this function
always tiers up to TurboFan.
Bug: v8:12013
Change-Id: I803bddaca8cb0ba0ad56cbd9874d90b118698e3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3053579
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75913}
The WebAssembly.Exception constructor creates a WasmExceptionPackage,
which represents an exception thrown from wasm. The first argument is a
WebAssembly.Tag, and the rest are the values to encode in the exception.
R=jkummerow@chromium.org
Bug: v8:11992
Change-Id: I1327b2e4545159397ffe73a061aa577608167b74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049074
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75912}
This is a reland of b99fe75c6d.
The test is now skipped on non-SIMD hardware.
Original change's description:
> [liftoff][arm64] Zero-extend offsets also for SIMD
>
> This extends https://crrev.com/c/2917612 also for SIMD, which
> (sometimes) uses the special {GetMemOpWithImmOffsetZero} method.
> As part of this CL, that method is renamed to {GetEffectiveAddress}
> which IMO is a better name. Also, it just returns a register to make the
> semantic of that function obvious in the signature.
>
> Drive-by: When sign extending to 32 bit, only write to the W portion of
> the register. This is a bit cleaner, and I first thought that
> this would be the bug.
>
> R=jkummerow@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: chromium:1231950, v8:12018
> Change-Id: Ifaefe1f18e3a00534a30c99e3c37ed09d9508f6e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049073
> Reviewed-by: Zhi An Ng <zhin@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75898}
TBR=zhin@chromium.orgCC=jkummerow@chromium.org, thibaudm@chromium.org
Bug: chromium:1231950, v8:12018
Change-Id: I662b62fafe99389be7a6c23b970fdf3768f866cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3051610
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75901}
This reverts commit b99fe75c6d.
Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/43105
Original change's description:
> [liftoff][arm64] Zero-extend offsets also for SIMD
>
> This extends https://crrev.com/c/2917612 also for SIMD, which
> (sometimes) uses the special {GetMemOpWithImmOffsetZero} method.
> As part of this CL, that method is renamed to {GetEffectiveAddress}
> which IMO is a better name. Also, it just returns a register to make the
> semantic of that function obvious in the signature.
>
> Drive-by: When sign extending to 32 bit, only write to the W portion of
> the register. This is a bit cleaner, and I first thought that
> this would be the bug.
>
> R=jkummerow@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: chromium:1231950, v8:12018
> Change-Id: Ifaefe1f18e3a00534a30c99e3c37ed09d9508f6e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049073
> Reviewed-by: Zhi An Ng <zhin@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75898}
Bug: chromium:1231950, v8:12018
Change-Id: I4e7a9d6fa6809b7c4d9be919cd5698737d784849
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049085
Auto-Submit: Michael Achenbach <machenbach@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/master@{#75900}
This extends https://crrev.com/c/2917612 also for SIMD, which
(sometimes) uses the special {GetMemOpWithImmOffsetZero} method.
As part of this CL, that method is renamed to {GetEffectiveAddress}
which IMO is a better name. Also, it just returns a register to make the
semantic of that function obvious in the signature.
Drive-by: When sign extending to 32 bit, only write to the W portion of
the register. This is a bit cleaner, and I first thought that
this would be the bug.
R=jkummerow@chromium.org
CC=thibaudm@chromium.org
Bug: chromium:1231950, v8:12018
Change-Id: Ifaefe1f18e3a00534a30c99e3c37ed09d9508f6e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049073
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75898}
This CL adds support for classes with methods.
More specifically:
- A new ValueSerializer is added and classes are serialized separetely
from functions, although the common parts are handled in the same way
and abstracted away.
- The function prototype is serialized as an object and any missing
information is set up again during deserialization.
- FunctionFlagsToFunctionKinds() is updated to allow for more function
kinds.
- Context serialization is updated to support serializing BlockContexts
and creating ScopeInfos of type CLASS_SCOPE.
- Map serialization is updated to support properties with custom
attributes.
Bug: v8:11525, v8:11706
Change-Id: I16ca7cbc17b1811721081cda05124ce36073f9be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3006416
Commit-Queue: Vicky Kontoura <vkont@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75893}
Enabling --turbo-optimize-apply breaks tests because we are
passing the wrong receiver;
in JSCallReducer::ReduceCallOrConstructWithArrayLikeOrSpread
we create a Call node with the wrong ConvertReceiverMode, we
pass kNullOrUndefined while it should be kAny. This may break
calls to API or in general calls to functions that use the
receiver.
Bug: chromium:1231108, v8:9974
Change-Id: Ib35a1bf8746ad254b6d63274f3ae11b12aa83de8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043690
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75886}
This reverts commit a5fd60e15a.
Reason for revert: As per crbug/1213374 this is not applied consistently. E.g. wrapping object into an array will bypass access checks. With the crrev/c/3041424 however, only accessible properties are shown in console, so logging a restricted object is no longer unsafe.
Original change's description:
> Calls to {console} require an access check for the provided arguments
>
> This CL adds an access check for the arguments to all calls to
> {console} like {console.log}. This is needed since the DevTools
> protocol notificiation event does not contain the context in which
> the {console.log} call occurred. Only the context of the argument.
> When DevTools then reads properties for the preview of the argument,
> it uses arguments context, instead of the calling context, potentially
> leaking objects/exceptions into the calling context.
>
> Bug: chromium:987502, chromium:986393
> Change-Id: I6f7682f7bee94a28ac61994bad259bd003511c39
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741664
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63122}
Bug: chromium:987502, chromium:986393, chromium:1213374
Change-Id: I92a8bb7663ff97de8831ddeb2c8560fb9fa1c12e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3046189
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Danil Somsikov <dsv@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75881}
Now that we have advanced division algorithms, we can implement
a divide-and-conquer strategy for toString-conversions, to make
their complexity sub-quadratic.
For example, this speeds up `(2n ** (2n ** 21n)).toString().length`
from 9400 ms to 200 ms on my laptop.
Bug: v8:11515
Change-Id: Id20f7f2928dc7308609f4c1688f32b252e04f433
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017805
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75880}
This is a reland of 84d5b027a7
It removes support for 8-byte types which were causing
unaligned reads.
Original change's description:
> [fastcall] Implement support for TypedArray arguments
>
> This CL adds TypedArrays as supported arguments for fast API calls.
> It implements "exact type" matching, i.e. if Float32Array is expected
> and e.g. Int32Array is passed instead, the generated code bails to the
> slow callback.
>
> Bug: chromium:1052746, chromium:1018624
> Change-Id: I01d4e681d2b367cbb57b06effcb591c090a23295
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999094
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75756}
Bug: chromium:1052746, chromium:1018624
Change-Id: I872716d95bde8c340cf04990a3e4ae8ec8cd74a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035090
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75877}
This properly threads through the `executionContextId` to the request
reported to the DevTools front-end, similarly to how we already report
the `executionContextId` as part of `Runtime.bindingCalled`.
Bug: chromium:1231521
Change-Id: I0a003041aedd8ec661d1b07cdddbcd1f2866a99f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3046187
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75875}
According to the spec https://tc39.github.io/proposal-error-cause,
the property 'cause' should not present on Error.prototype.
Bug: v8:12006
Change-Id: Ib1601769793b808c5f5a7065effcc77d1def4cbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3037911
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75872}
The test is flaky on that hardware but seems to work just fine on other
arm hardware.
R=machenbach@chromium.org
Bug: v8:10948
Change-Id: Ic60cc23c1b4825623a91e3defcd21eada74554a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043954
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75867}
The intrinsic default proto was not installed on async
function constructor, so the proto for those unable to
get a proper receiver fallbacks to the realms'
%Object.prototype%.
Bug: v8:9818
Change-Id: I08b9459d60da72dc894b983973e0a36019be9141
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043691
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75866}
And use it to remove the set of TurboProp test skips.
BUG=v8:9684,v8:12013
Change-Id: I878e2b9c595449c954735290959d3b38eead5a5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043963
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75865}
...while on-heap objects are referring to it. This is accomplished
by storing a reference to its associated WasmInstanceObject on every
WasmTypeInfo object.
Details: https://bit.ly/2UxD4hW
Fixed: v8:11953
Change-Id: Ifb6f976142356021393d41c50717d210d525d521
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043959
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75863}
Some skips are no longer required.
BUG=v8:9684
Change-Id: I921f2032ea5c19429c735120ba80a09b8f1e352e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043961
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75854}
Adds incompatibility between future/turboprop variants and stress-concurrent-inlining
due to incompatibility from both configs weakly setting --interrupt-budget. Also ensures
we maintain this incompatibility if --future is passed as an extra flag as is done on
some bots.
BUG=v8:9684
Change-Id: I4855b92a64db00da15efc2384e241d4bf0c373c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041677
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75853}
RegExp match indices have shipped since M90
Bug: v8:9548
Change-Id: I8bf54ce1a50b5079aad71140f75c979a09aae5bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3042842
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75848}
This is a reland of 4cc547c759
Change: prevent a memcpy to nullptr by skipping the call to copy_out()
when the length is zero.
Original change's description:
> [wasm][eh] Add WebAssembly.Tag.type
>
> R=ahaas@chromium.org
>
> Bug: v8:8091
> Change-Id: Id069ffbf76bf836b613287788b1b1fccbb577475
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021173
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75815}
Bug: v8:8091
Change-Id: I22f400b6e36d1322a4eabd20a68b4bdd70d61377
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041436
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75847}
Allow CrossThreadPersistent and its weak form to access ASAN poisoned
memory from the GC entry points.
In general, payloads of to-be-finalized objects are poisoned until the
finalizer actually runs to avoid accidentally touching that payload.
In the case of cross-thread handles, these may need to be cleared by a
different thread before the finalizer actually runs. In order to clear
those references, the slot needs to be unpoisoned.
This is issue is ASAN-only and does not affect production or other
debug builds.
Bug: chromium:1230599, chromium:1056170
Change-Id: If4d0808953047319b02653821abbb5c638084dc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040845
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75846}
This adds a little {Simulator::ProbeMemory} method that is used from
several places in the arm64 simulator to test if a memory address can be
accessed, and trigger a signal from a specific location such that the
trap-handler can handle it. In case of a trap, the simulator is
redirected to the landing pad and stops executing the memory
instruction that triggered the trap.
Standard memory accesses and SIMD memory loads and stores are
instrumented to probe the memory. This passes all existing tests. In
case this CL misses certain spots, we can still add them later. This
will not be a security problem, since we do not use the simulator in
production.
R=ahaas@chromium.orgCC=mseaborn@chromium.org, v8-arm-ports@googlegroups.com
Bug: v8:11955
Change-Id: I52a81341e99fabc5fcf9e41ef4d8dd2226092803
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015557
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75843}
The concurrent sweeper destroyed large pages directly in case no
finalizer was needed during sweeping. This is unsafe as the logic of
BasePage::Destroy is not concurrency safe.
Bug: chromium:1056170, chromium:1231053
Change-Id: I8ae9b27b916f8c4aee0c239c7ac8f2ec61d92c56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041671
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75842}
Since most Torque-defined extern classes use @generateCppClass, it makes
more sense to instead annotate the small number that don't. This is part
of the cleanup work that Nico recommended in [1].
Classes that still have to opt out:
- Those that can be converted by https://crrev.com/c/3015666
- HeapObject: sort of special since it's the root of the inheritance
hierarchy. Generated code would include two declarations that don't
compile until HeapObject is defined:
bool IsHeapObject_NonInline(HeapObject o);
explicit TorqueGeneratedHeapObject(
Address ptr, HeapObject::AllowInlineSmiStorage allow_smi);
- SmallOrdered*: these classes use templates on the C++ side, which is
not currently representable in Torque.
- SwissNameDictionary: according to a comment, the Torque generation for
this class is incorrect. I haven't investigated further.
Drive-by fix: make the Torque formatter keep LF on Windows rather than
writing CRLF.
[1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit#
Bug: v8:8952
Change-Id: I1fbb5290f0c645842b84c53816c09bb3398206a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3028721
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#75841}
We add additional num_types and liftoff parameters
for GetValueType to be able to generate user-def reftypes.
num_types is the number of types in the program and
liftoff checks if we could add reftypes or not.
The additional method (NumTypes) was added to WasmModuleBuilder and
additional field (liftoff) to WasmGenerator constructor.
Bug: v8:11954
Change-Id: I4904a41043264c65d5cba5b22129184d6a486bfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041426
Commit-Queue: Rakhim Khismet <khismet@google.com>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75840}
Currently deopt fuzzer passes --future and so should skip the same tests
as the future variant.
BUG=v8:9684
Change-Id: I3d10dae7ba7cffc36bd4777941ac053c42c80cef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041668
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75835}
With lazy feedback allocation we don't tier up to baseline early. This
test requires us to tier up to baseline. So add
--lazy_feedback_allocation as a required flag.
Bug: v8:12009
Change-Id: Ibbc1d1cc74ae368ef414f513a0cd46e9bf068186
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3042718
Commit-Queue: Mythri Alle <mythria@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75829}
This makes the V8 dcheck control independent of Chromium's and
prepares switching Chromium's default behavior without affecting V8
developers or builders.
Preparation for: https://crrev.com/c/2893204
Bug: chromium:1225701
Change-Id: I520b96019b04196f4420716ff3500ebd6c21666f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038528
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75827}
Hashing FunctionSigs can be quite expensive for large modules;
luckily in some cases we can avoid doing that work.
Change-Id: Ia18060b4c27ab34b44bda4bb81ea05299ecb0f49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038523
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75819}
This CL fixes a previous change in String.prototype.startsWith which
didn't throw an exception (in the optimized version) when `undefined`
was passed as a receiver and the search string was the empty string.
Bug: chromium:1230260
Change-Id: I835bd409b09b78bf7235c77596f62b588c95611d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040841
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75818}
This is a reland of ea55438a53. Relanding
after a fix lands here:
https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures
were caused because baseline code could be flushed during the process
of deoptimization after we choose which entry (InterpreterEnterAt* /
BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect
baseline code but it could be flushed before we execute the builtin. The
fix is to defer the decision.
Original change's description:
> [sparkplug] Support bytecode / baseline code flushing with sparkplug
>
> Currently with sparkplug we don't flush bytecode / baseline code of
> functions that were tiered up to sparkplug. This CL adds the support to
> flush baseline code / bytecode of functions that have baseline code too.
> This CL:
> 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
> JSFunction as a custom weak pointer where the code is treated as weak if
> the bytecode corresponding to this function is old.
> 2. Updates GC to handle the functions that had a weak code object during
> the atomic phase of GC.
> 3. Updates the check for old bytecode to also consider when there is
> baseline code on the function.
>
> This CL doesn't change any heuristics for flushing. The baseline code
> will be flushed at the same time as bytecode.
>
> Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
> Bug: v8:11947
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75674}
Bug: v8:11947
Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75810}
This is a reland of 431fff66f5.
The fix is in BUILD.gn: We need to also include chromeos, which is a
linux target which is not covered by "is_linux" in gn.
R=ahaas@chromium.org
Original change's description:
> [traphandler] Add simulator support
>
> This prepares the trap handler to support being used from simulators.
> Modifications to the arm64 simulator will be done in a follow-up CL. For
> now, the trap handler will be registered but not used in Wasm (we emit
> explicit bounds checks instead, as before).
>
> The implementation uses inline assembly, so it is only available on x64
> POSIX systems for now. This is the main platform we use for testing and
> for fuzzing, so it should give us the test coverage we need. If needed,
> inline assembly for other platforms can be added later.
> The new code will be executed by the existing arm64 simulator bots, e.g.
> "V8 Linux - arm64 - sim".
>
> R=ahaas@chromium.org, mseaborn@chromium.org
>
> Bug: v8:11955
> Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75780}
Bug: v8:11955
Change-Id: I8af39dea5b2cd3fa5418170a458832b3d6075107
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040844
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75809}
GC may change heap state and make this dependency fail. That's okay -
it passed once before, meaning that compilation saw a self-consistent
JSFunctionRef state.
Bug: chromium:1230930
Change-Id: I367b10e4aa88101f1ca83a46f596c5f289f6cab2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040838
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75802}
This reverts commit 431fff66f5.
Reason for revert: Causes link error in chrome: https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20ChromiumOS%20MSan%20Builder/24667/overview
Original change's description:
> [traphandler] Add simulator support
>
> This prepares the trap handler to support being used from simulators.
> Modifications to the arm64 simulator will be done in a follow-up CL. For
> now, the trap handler will be registered but not used in Wasm (we emit
> explicit bounds checks instead, as before).
>
> The implementation uses inline assembly, so it is only available on x64
> POSIX systems for now. This is the main platform we use for testing and
> for fuzzing, so it should give us the test coverage we need. If needed,
> inline assembly for other platforms can be added later.
> The new code will be executed by the existing arm64 simulator bots, e.g.
> "V8 Linux - arm64 - sim".
>
> R=ahaas@chromium.org, mseaborn@chromium.org
>
> Bug: v8:11955
> Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75780}
Bug: v8:11955
Change-Id: I74d2e41864fc515bd9727898f12ec1498b97ee62
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040839
Auto-Submit: Clemens Backes <clemensb@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/master@{#75798}
This wraps up the transition away from kSerialized ref kinds.
Since JSFunctionRef is a complex type, we don't attempt full
consistency on the background thread. Instead, we serialize functions
on the background in a partially-racy manner, in which consistency
between different JSFunction fields is *not* guaranteed. Consistency
is later verified through a new compilation dependency kind during
finalization.
Bug: v8:7790, v8:12004
Change-Id: Ic2b78af9c9fe183c8769d323132bb304b151dc75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968404
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75789}
This is a reland of 0b091e9bd3
Some blink web tests have been temporarily disabled to allow landing
changes to the JS API in V8.
Original change's description:
> [wasm][eh] Rename Exception to Tag in the JS API
>
> See:
> https://github.com/WebAssembly/exception-handling/issues/159
>
> This change only does the rename where it's observable. This should also
> be renamed throughout the codebase for consistency and will be done
> separately.
>
> R=ahaas@chromium.org
>
> Bug: v8:8091
> Change-Id: Iec1118194981dfd33be6e30256b6e72d12143e1f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021172
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75718}
Bug: v8:8091
Change-Id: Id5375b5287fff81b8e0096377a55ef63e6d9b985
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035083
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75785}
We add a struct type and array type to the fuzzed module.
Since the interpreter does not support wasm-gc,
we only do so if liftoff is used as a reference implementation.
Also, adding liftoff parameter to all GenerateModule definitions.
Bug: v8:11954
Change-Id: Ia8d2d7a8e1e12d375605f15d1393dd64f426607d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024160
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Rakhim Khismet <khismet@google.com>
Cr-Commit-Position: refs/heads/master@{#75782}
This prepares the trap handler to support being used from simulators.
Modifications to the arm64 simulator will be done in a follow-up CL. For
now, the trap handler will be registered but not used in Wasm (we emit
explicit bounds checks instead, as before).
The implementation uses inline assembly, so it is only available on x64
POSIX systems for now. This is the main platform we use for testing and
for fuzzing, so it should give us the test coverage we need. If needed,
inline assembly for other platforms can be added later.
The new code will be executed by the existing arm64 simulator bots, e.g.
"V8 Linux - arm64 - sim".
R=ahaas@chromium.org, mseaborn@chromium.org
Bug: v8:11955
Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75780}
Slightly lowers the interrupt budget for Turboprop and increases the
interrupt budget scaling factor for TurboFan. This gives the best
balance between benchmark performance and reducing optimization
overhead.
BUG=v8:9684
Change-Id: I6d555fb27d089bc8a6849612a4e02b2155020d85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3026713
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75764}
This CL fixes the behaviour of String.prototype.startsWith when
undefined is passed as the search term. It also implements a small
shorthand when the search term is empty (according to the spec).
Bug: v8:11977
Change-Id: Iec2aa5f4301fcf444f20d5c1a80d3f634624d6f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035089
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75763}
This CL adds TypedArrays as supported arguments for fast API calls.
It implements "exact type" matching, i.e. if Float32Array is expected
and e.g. Int32Array is passed instead, the generated code bails to the
slow callback.
Bug: chromium:1052746, chromium:1018624
Change-Id: I01d4e681d2b367cbb57b06effcb591c090a23295
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999094
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75756}
When the FFT multiplication algorithm invokes itself for the
recursive steps, the input is "mod Fn"-normalized, i.e. it is
at most of the shape (1 << N), but we only read N bits of it,
so in the rare case where it was exactly 1 << N, that lone top
bit was ignored, leading to an incorrect result of the overall
multiplication.
Fixed: chromium:1228267
Change-Id: I7b245fc3701696d95e5d75fb970f02d72ce40ff8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3032081
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75755}
Just like many other operations implemented in elements.cc, copyWithin
also needs to use relaxed atomics if operating on a shared array buffer
to avoid races with other threads.
Since the ranges can overlap, this CL also adds a {Relaxed_Memmove}
function that either copies forwards (like {Relaxed_Memcpy}) or
backwards depending on the ordering of source and destination.
R=leszeks@chromium.org
Bug: chromium:1221035
Change-Id: I76b7e43810ac9b85f4ff9abbc5a0406618771c25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3032084
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75752}
Dividing by first computing a multiplicative inverse is faster than
Burnikel-Ziegler division for very large inputs.
Bug: v8:11515
Change-Id: Ice45690c3fa4eef7102d418cdd3d82a942a076c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015573
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75743}
This removes the low-level {SwitchMemoryPermissionsToWritable()} and
{SwitchMemoryPermissionsToExecutable()} functions. They are only used in
tests and can be replaced by {CodeSpaceWriteScope} objects that we also
use in production.
R=jkummerow@chromium.org
Change-Id: I7ba702c836f3ac2dd7c7a81d6362040b28e8bef4
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024150
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75739}
This test is only testing a d8-specific feature, so there's no need to
test it under a wide variety of conditions. And at the moment its
flakiness in the arm64/debug/simulator config are blocking the v8 roll.
Change-Id: I35456989f7875331a415ca3ff478c67a8e7e79bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027743
Commit-Queue: Adam Klein <adamk@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Adam Klein <adamk@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75728}
This reverts commit 0b091e9bd3.
Reason for revert: Causes Web Platform Test failures, blocking roll
E.g., https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Linux/12616/overview
Original change's description:
> [wasm][eh] Rename Exception to Tag in the JS API
>
> See:
> https://github.com/WebAssembly/exception-handling/issues/159
>
> This change only does the rename where it's observable. This should also
> be renamed throughout the codebase for consistency and will be done
> separately.
>
> R=ahaas@chromium.org
>
> Bug: v8:8091
> Change-Id: Iec1118194981dfd33be6e30256b6e72d12143e1f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021172
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75718}
Bug: v8:8091
Change-Id: Id2067e1cdc33fa657ef738ef5fafad84057f7209
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027261
Auto-Submit: Adam Klein <adamk@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/master@{#75725}
Also, copying hints can be removed from literals. Shallow
copying wasn't used for some time, because of the
way we treat mutable heap numbers.
Change-Id: Ieeba44a9f8e80c4183af8f4751f68dd3a542532e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009230
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75717}
This avoids a DCHECK failure if we continue using the Assembler after
code generation abortion. Even though it might not be the best style to
still call methods on the Assembler after abortion, it's not a problem
apart from the firing DCHECK, so we apply this simple fix instead of
making sure to really abort everything immediately.
R=leszeks@chromium.org
Bug: chromium:1228720, chromium:1217074
Change-Id: Iac3a652f21e34534dd28fb1ab580ab2ee6df06dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024157
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75716}
This is a reland of dcdaf42fa8. It adds
CPU time metrics to the WasmModuleDecoded (except for streaming),
WasmModuleCompiled and WasmModuleTieredUp events. This can later be used
to provide this information as UKMs or UMAs.
Bug: v8:11611
Change-Id: I813fc8de36d1445c6a887abf496ec10e1a803815
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953296
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75715}
Added a parameter to Object::FitsRepresentation() to disallow coercion.
Normally, when we ask if a Smi can "fit" into a Double representation
we'd answer yes, because the Smi can be converted to a HeapNumber.
However, from the compilers perspective, the object is found in a
field with a particular representation. In this case, finding a
Smi in a field with representation Double means something is awry.
Therefore, it's useful for the compiler to be able to ask if
the object fits the field without coercion.
Bug: chromium:1227324, v8:7790
Change-Id: I12033736030d904ef9c29516c07999600a5f508a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015570
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75706}
Mark --turbo-fast-api-calls flag as incompatible with stress_snapshot
variant to avoid listing all related tests in the status file.
Change-Id: If130780461e50e72ea6a43d750b2f7ad7764db2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024147
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75705}
When there are multiple entries into a deferred block region, ensure
that we freeze the set of deferred spill virtual registers when we have
processed the first entry point to that deferred block. This ensures
that we don't add another vreg into the set of deferred spills, and
then specify that that deferred spill slot is live across the whole
deferred block, when it is only live from certain entry points.
BUG=chromium:1227568,v8:9684
Change-Id: I647851be9a00fba262768e4f1a7846669b585a2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021178
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75704}
- Implement f32/f64 fcopysign
- Implement f32/f64 type conversion
- enable some test cases that now pass.
Change-Id: Ia36299484adac885349df25d7c233dd7e43dded4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992914
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ji Qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/master@{#75690}
Now that code entries outlive our CodeMap, it's safe to avoid storing
CodeMap metadata after the last active profiler stops. This simplifies
lifecycle logic, and avoids retaining stale data.
Bug: v8:11054
Change-Id: If30fc0835e2033b5bcca204565e05a5cba7823ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3000526
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75689}
Port fb28cfe603
Original Commit Message:
So far, discarded size was maintained by the sweeper but not wired up
anywere.
Changes in this patch:
- Wire up resident size in heap statistics collection.
- Fix bugs in reporting committed and resident size.
- Sweeper test: Enforce some internal details. The details should not
not be checked broadly but be kept as a detail to the sweeper
itself.
- Stats collection: Test that committed and resident set size are
reported and differ after discarding GCs.
R=mlippautz@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I19be251596ccc955f5c4cd43a46e566001a36ac4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021468
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#75688}
So far, discarded size was maintained by the sweeper but not wired up
anywere.
Changes in this patch:
- Wire up resident size in heap statistics collection.
- Fix bugs in reporting committed and resident size.
- Sweeper test: Enforce some internal details. The details should not
not be checked broadly but be kept as a detail to the sweeper
itself.
- Stats collection: Test that committed and resident set size are
reported and differ after discarding GCs.
Bug: chromium:1056170
Change-Id: Icf8871c7ea3b28253233485c736b2ca4816fd6f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3020971
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75684}
Monotonicity of typing of arithmetic operations could fail in the
presence of optimized_out Oddball inputs, which can arise in dead code
in resumable functions. The CL fixes these with a small change to
BinaryNumberOpTyper.
Bug: chromium:1227677
Change-Id: I1e1d2e174b757e839d776685f52f7c4ac900844b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3020972
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75683}
This reverts commit ea55438a53.
Reason for revert: Likely culprit for these failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20NumFuzz/15494/overview
Original change's description:
> [sparkplug] Support bytecode / baseline code flushing with sparkplug
>
> Currently with sparkplug we don't flush bytecode / baseline code of
> functions that were tiered up to sparkplug. This CL adds the support to
> flush baseline code / bytecode of functions that have baseline code too.
> This CL:
> 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
> JSFunction as a custom weak pointer where the code is treated as weak if
> the bytecode corresponding to this function is old.
> 2. Updates GC to handle the functions that had a weak code object during
> the atomic phase of GC.
> 3. Updates the check for old bytecode to also consider when there is
> baseline code on the function.
>
> This CL doesn't change any heuristics for flushing. The baseline code
> will be flushed at the same time as bytecode.
>
> Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
> Bug: v8:11947
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75674}
Bug: v8:11947
Change-Id: I50535b9a6c6fc39eceb4f6c0e0c84c55bb92f30a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017811
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75679}
A single ClusterFuzz report flushed out two minor issues in the
bit fiddling routines.
Bug: chromium:1227752,v8:11515
Change-Id: I16ab914b7c3859f55aa141ced371dd80171d0cb5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017809
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75678}
Currently with sparkplug we don't flush bytecode / baseline code of
functions that were tiered up to sparkplug. This CL adds the support to
flush baseline code / bytecode of functions that have baseline code too.
This CL:
1. Updates the BodyDescriptor of JSFunction to treat the Code field of
JSFunction as a custom weak pointer where the code is treated as weak if
the bytecode corresponding to this function is old.
2. Updates GC to handle the functions that had a weak code object during
the atomic phase of GC.
3. Updates the check for old bytecode to also consider when there is
baseline code on the function.
This CL doesn't change any heuristics for flushing. The baseline code
will be flushed at the same time as bytecode.
Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
Bug: v8:11947
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75674}
Instantiation was inside a DCHECK and therefore did not happen in
non-debug modes. Turn the DCHECK into a CHECK.
R=clemensb@chromium.org
Bug: chromium:1227685
Change-Id: I13240109326a2c94576f6651963543187d96ad3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017806
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75673}
This CL implements the resolution of function overloads based on
run-time checks of the type of arguments passed to the JS function.
For the moment, the only supported overload resolution is between
JSArrays and TypedArrays.
Bug: v8:11739
Change-Id: Iabb79149f021037470a3adf071d1cccb6f00acd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2987599
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#75664}
The Schönhage-Strassen method for *very* large inputs.
This is a reland of 347ba35716,
with added zero-initialization to pacify MSan (spurious report).
Originally:
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3000742
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75659}
Bug: v8:11515
Change-Id: Ieac6e174bde6eb09af0a9a9a49969feabca79e81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3018081
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75663}
Reset the instance before the test run, to ensure it runs with the
same initial state as the reference run.
R=clemensb@chromium.org
Bug: chromium:1227591
Change-Id: Ie78b4b84e3df37ab8955c240f1d41e2f5e89a5de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015572
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75658}
We cannot emit the constant pool within the safepoint table data. It
seems like we also don't do that, but the forgotten
{BlockConstPoolScope} triggered a DCHECK.
R=leszeks@chromium.org
Bug: chromium:1227351, chromium:1217074
Change-Id: I187004c83e05002c651a15643bddea5b02cb00c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015559
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75657}
This is a reland of 819c3ae2f8
Original change's description:
> Reland "Reland "Improve error messages for property access on null/undefined""
>
> This is a reland of 8b18c5e6a5
>
> Original change's description:
> > Reland "Improve error messages for property access on null/undefined"
> >
> > This is a reland of 24c626c1f7
> >
> > Original change's description:
> > > Improve error messages for property access on null/undefined
> > >
> > > Only print the property name when accessing null/undefined if we can
> > > convert it to a string without causing side effects.
> > > If we can't, omit the property name in the error message.
> > > This should avoid confusion when the key is an object with toString().
> > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
> > > Object]' anymore, which was misleading since the property accessed would
> > > be 'a', but we can't evaluate the key without side effects.
> > >
> > > Bug: v8:11365
> > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#75250}
> >
> > Bug: v8:11365
> > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#75571}
>
> Bug: v8:11365
> Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
> Auto-Submit: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75604}
Bug: v8:11365
Change-Id: I002b537144f328ccbbdcd655e26e5dc87c49c6f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013935
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75645}
The stack overflow used to occur when too many bound functions
are nested. The CL also adds a regression test.
Bug: chromium:1226264
Change-Id: I34329d8392d2385207dbd9a8d3188ad4f7cb3c2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011161
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75640}
The JSCallWithArraylike can be replaced with a JSCall if its probable arguments list is empty literal array. This replacement will introduce a deoptimization check to make sure the length of arguments list is 0 at runtime.
This CL change this optimization to a diamond speculation which may help avoid deoptimization once and keep the fast path. This change may benefit a following usecase,
function calcMax(testArray) {
Array.max = function(array) {
return Math.max.apply(Math, array);
};
var result = [];
for (var i = 0; i < testArray.length - 3; i++) {
var positiveNumbers = [];
for (var j = 0; j < 3; j++) {
if (testArray[i + j] > 0) {
positiveNumbers.push(testArray[i + j]);
}
}
result.push(Array.max(positiveNumbers));
}
return result;
}
testArray = [-1, 2, 3, -4, -5, -6, -7, -8, -9, 10];
for (var i = 0; i < 1000000; i++) {
calcMax(testArray);
}
Bug: v8:9974
Change-Id: I595627e2fd937527350c8f8652d701c791b41dd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967757
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75636}
Add an option to use Liftoff instead of the interpreter as the reference
tier for fuzzing. The tier to use is chosen based on the input data
before generating the module. This way, the module can use features
depending on what is available in the reference tier, and we still get a
chance to find correctness issues that would only be detected by the
interpreter.
R=clemensb@chromium.org
Bug: v8:11856
Change-Id: I2e9878345355a37caec5fdb338dda42a84e8e63a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008645
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75633}
Trap handling is not implemented yet for memory64. Make sure that no
code tries to use it, by setting {NativeModule::bounds_checks_}
accordingly.
This requires some changes to tests to make sure that the
{WasmModule::is_memory64} field is set before creating the corresponding
{NativeModule}.
R=ahaas@chromium.org
Bug: v8:10949
Change-Id: I11d9544b603fc471e3368bb4e7487da4711293a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011167
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75632}
This reverts commit 819c3ae2f8.
Reason for revert: Sorry Patrick, still failing on some layout tests :( https://test-results.appspot.com/data/layout_results/mac-rel/726365/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html
Original change's description:
> Reland "Reland "Improve error messages for property access on null/undefined""
>
> This is a reland of 8b18c5e6a5
>
> Original change's description:
> > Reland "Improve error messages for property access on null/undefined"
> >
> > This is a reland of 24c626c1f7
> >
> > Original change's description:
> > > Improve error messages for property access on null/undefined
> > >
> > > Only print the property name when accessing null/undefined if we can
> > > convert it to a string without causing side effects.
> > > If we can't, omit the property name in the error message.
> > > This should avoid confusion when the key is an object with toString().
> > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
> > > Object]' anymore, which was misleading since the property accessed would
> > > be 'a', but we can't evaluate the key without side effects.
> > >
> > > Bug: v8:11365
> > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#75250}
> >
> > Bug: v8:11365
> > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#75571}
>
> Bug: v8:11365
> Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
> Auto-Submit: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75604}
Bug: v8:11365
Change-Id: I7d7c0f201288384c2aa38a51418b582a64213ae0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013352
Auto-Submit: 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/master@{#75626}
We had some (dead) logic to create different parameter values pending on
the position of the parameter. As it was not used any more, it got
removed in https://crrev.com/c/3003464.
This CL changes the existing logic for creating default parameter values
to use a similar logic, which matches what --wasm-fuzzer-gen-test
creates and has a slightly higher chance of triggering interesting
behaviour.
R=ahaas@chromium.org
Change-Id: Ibb4394c1978f25d70166a03002e084211bfe7e1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3003465
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75619}
The bugfix yesterday missed a case (CL
758816f438).
A better approach is to compute the ideal representation of the
value, then check if it can be in-place changed to the
recorded representation.
Bug: chromium:1226988, v8:7790
Change-Id: I90e58b8efb83892c033693a1a0f946b3059a330c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011162
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75615}
Behind a new --experimental-wasm-nn-locals flag.
The checking policy implemented here is that locals count as
initialized until the end of the current control structure,
as described here:
https://github.com/WebAssembly/function-references/issues/44#issuecomment-801977331
Bug: v8:7748
Change-Id: I954fdf1b4e02ed4b45ef61b8379b7c0bbe802400
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3010283
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75613}
This CL implements GC in a shared heap. A shared GC is started from
an attached client isolate that fails to allocate a shared object. In
order to perform a shared GC all other running client isolates need
to be stopped and their roots need to be scanned.
Bug: v8:11708
Change-Id: I45ac50e6b4a1e9270f9e39b69f9b8ee5e6e14134
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964816
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75606}
This is a reland of 8b18c5e6a5
Original change's description:
> Reland "Improve error messages for property access on null/undefined"
>
> This is a reland of 24c626c1f7
>
> Original change's description:
> > Improve error messages for property access on null/undefined
> >
> > Only print the property name when accessing null/undefined if we can
> > convert it to a string without causing side effects.
> > If we can't, omit the property name in the error message.
> > This should avoid confusion when the key is an object with toString().
> > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
> > Object]' anymore, which was misleading since the property accessed would
> > be 'a', but we can't evaluate the key without side effects.
> >
> > Bug: v8:11365
> > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#75250}
>
> Bug: v8:11365
> Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75571}
Bug: v8:11365
Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75604}
We did not handle conflicts between regular register moves and the
cached instance / cached memory start correctly. This could lead to us
overwriting a regular register when restoring the cached instance, which
results in either crashes or miscalculations afterwards.
R=ahaas@chromium.org
Bug: chromium:1217064
Change-Id: Icd4b08b97a47726108a50d51b3a7ba410d132f98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3003158
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75602}
The {TestingModuleBuilder} had separate logic to compute the bounds
checking strategy. This can lead to compiled code that does not match
the bounds checking strategy stored in the NativeModule. Hence, tests
should use {NativeModule::bounds_checks_} for initializing their
compilation environment.
R=ahaas@chromium.org
Change-Id: I366c2ea5d06062273fa21e388871fc1adab54fef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009222
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75601}
A generalization of Karatsuba's idea for even larger inputs.
Bug: v8:11515
Change-Id: I50eac2d313bf4217bf2f55ca2e64b5f120f40206
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999870
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75598}
In GetOwnFastDataPropertyFromHeap, we read a property value
then compare it with the expected representation. We already
had code to bail out of that particular optimization if there
was a mismatch, however it missed the case of expected
representation being a HeapObject, and when a Smi value was found.
The fix is to use the excellent pre-existing method
Object::FitsRepresentation() to make this check. Thusly, all
cases are handled.
Bug: chromium:1225607, v8:7790
Change-Id: I7d9b1b7722d9691cf5427f8456a6deb466dda0d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008218
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75587}
TurboFan reads the value in HeapNumber, and TSAN detects a data
race between this read and sets on the main thread elsewhere.
We mark this as relaxed atomic (meaning, correct value of the read
is not guaranteed). The compiler uses the dependency mechanism
to re-read the value safely on the main thread later, and aborts
compilation if a change is detected.
Bug: chromium:1224277, v8:7790
Change-Id: I8931d8989812550c0c57b6bd27aa796f6f5e779d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996201
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75586}
This reverts commit 8b18c5e6a5.
Reason for revert: Still failing: https://test-results.appspot.com/data/layout_results/V8_Blink_Linux/12469/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html
Original change's description:
> Reland "Improve error messages for property access on null/undefined"
>
> This is a reland of 24c626c1f7
>
> Original change's description:
> > Improve error messages for property access on null/undefined
> >
> > Only print the property name when accessing null/undefined if we can
> > convert it to a string without causing side effects.
> > If we can't, omit the property name in the error message.
> > This should avoid confusion when the key is an object with toString().
> > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
> > Object]' anymore, which was misleading since the property accessed would
> > be 'a', but we can't evaluate the key without side effects.
> >
> > Bug: v8:11365
> > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#75250}
>
> Bug: v8:11365
> Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75571}
Bug: v8:11365
Change-Id: Ic4137f0d70fa9b10ca70fa921b98ea7e1499f11b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008217
Auto-Submit: 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/master@{#75577}
This is a reland of 24c626c1f7
Original change's description:
> Improve error messages for property access on null/undefined
>
> Only print the property name when accessing null/undefined if we can
> convert it to a string without causing side effects.
> If we can't, omit the property name in the error message.
> This should avoid confusion when the key is an object with toString().
> E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
> Object]' anymore, which was misleading since the property accessed would
> be 'a', but we can't evaluate the key without side effects.
>
> Bug: v8:11365
> Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75250}
Bug: v8:11365
Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75571}
The new DCHECK fires when the tier was set to {kNone}, which was the
case for wrappers.
Since the compiler is only interesting for proper Wasm functions, we
keep the DCHECK but only print the compiler for code objects that
represent actual Wasm functions.
R=thibaudm@chromium.org
Bug: chromium:1223839
Change-Id: Icc0f13b34b53fee2a8d53857a4769ab4d80ab805
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3003467
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75562}
The number of arguments and their values were generated and passed by
the individual fuzzers, but were unused by the caller. Instead, default
arguments are generated in {MakeDefaultInterpreterArguments} and
{MakeDefaultArguments}.
Thus this CL removes the dead parameters and assignments.
R=ahaas@chromium.org
Change-Id: I5ca5b06a0848c2a89e70ed739f44bc2161fcb2bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3003464
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75560}
This is a three-state field now: kTrapHandler, kExplicitBoundsChecks,
kNoBoundsChecks. It is set once based on the flags
(--wasm-bounds-checks and --wasm-enforce-bounds-checks) and depending on
whether the signal handler for wasm trap handling was installed. All
compilation then only uses the field value, and does not need to check
any flags any more.
R=ahaas@chromium.org
Bug: v8:11926
Change-Id: I2c0eb5ecb742ee65d1c10e4dceff7204119dab7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996191
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75558}
In order to implement eager (side effect free) evaluation of arbitrary
accessor properties correctly, we need the ability to call getters while
guaranteeing that we don't trigger side effects. This is accomplished by
adding a `throwOnSideEffect` flag to the `Runtime.callFunctionOn` API,
similar to what's already available with the `Runtime.evaluate` and the
`Debugger.evaluateOnCallFrame` APIs.
Bug: chromium:1076820, chromium:1119900, chromium:1222114
Change-Id: If2d6c51376669cbc71a9dd3c79403d24d62aee43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001360
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75556}
A frame state's outer frame state input can be kDeadValue. A DCHECK
did not take that into account. In release builds there was no issue
because we branch on the opcode anyways.
While fixing this bug, I'm strengthening the FrameState class such that
a FrameState node must have a kFrameState operator. I'm also
- changing the result type of outer_frame_state() from FrameState to
Node* since it may in fact not be a kFrameState;
- removing has_outer_frame_state() because I find it unintuitive to
have outer_frame_state() return non-NULL even when
has_outer_frame_state() would return true.
Bug: chromium:1224758
Change-Id: I8ebed75c62e31f7eef71e2941fd18869d8a56af3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001356
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75553}
Commit 26d85acee2 "Use IMMEDIATE_CRASH on
official build FATAL errors." has changed how FATAL macro behaves on
such builds. Unfortunately this affects logging and
random number generator v8 unittests which use ASSERT_DEATH_IF_SUPPORTED
macro. After the change we no longer get any v8 CHECK crash messages on
official builds thus failing those tests.
Fix this by adjusting failing test expectations to reflect the new,
expected results v8 now has on official builds.
Change-Id: Ice9718c5e887b42a0cfd583340256f7d2591add4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2991238
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75547}
