- 26 May, 2022 6 commits
-
-
Manos Koukoutos authored
We inline array allocation for wasm-gc in the TF graph by using AllocateRaw nodes. Additionally, we use memset to initialize large, zero-initialized arrays. These changes give measurable speedup in some benchmarks. Bug: v8:7748 Change-Id: Icbd37d0fe673c673379139b96d0e1c175e95e357 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3666618Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#80762}
-
Andrey Kosyakov authored
This lets us accept spec-compliant CBOR tag for message envelopes. This also includes a change in v8-inspector-session-impl.cc that relaxes an envelope check to allow spec-compliant envelopes. Change-Id: Id77c1e0fc4b62d78e8580f81ef38d50e3eb54a1d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3662540Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Andrey Kosyakov <caseq@chromium.org> Cr-Commit-Position: refs/heads/main@{#80761}
-
Rob Paveza authored
Initialization after reset + unnecessary use of handle scope appear to be the culprit here. Most of the other functions in debug::Script do not use HandleScope, so this reconciles these differences. Additionally, the call to obtain and initialize the hash within ActualScript::Initialize was inconsistent: all of the other fields were initialized prior to resetting the script and source. These reconciliations appear to fix this crash. Bug: chromium:1325036 Change-Id: Ia86e83b6c99955a3ac80a4a8845c0df0172e991c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3648082 Commit-Queue: Robert Paveza <Rob.Paveza@microsoft.com> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Auto-Submit: Robert Paveza <Rob.Paveza@microsoft.com> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#80760}
-
Lu Yahan authored
Port commit 22a16bda Change-Id: I1a6815ca22f4b931ffd2468d8aeb82dc7a1e2bc5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3669661 Commit-Queue: ji qiu <qiuji@iscas.ac.cn> Reviewed-by:
ji qiu <qiuji@iscas.ac.cn> Auto-Submit: Yahan Lu <yahan@iscas.ac.cn> Cr-Commit-Position: refs/heads/main@{#80759}
-
Jakob Kummerow authored
We can simply trap in the runtime, instead of returning sentinels. Bug: v8:7748, v8:12425 Change-Id: I179c8675fabd3cb730f002ba99ba8cf942a9d4ec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3669108Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#80758}
-
Frank Tang authored
Spec Text: https://tc39.es/proposal-temporal/#sec-temporal.plaintime.prototype.toplaindatetime Bug: v8:11544 Change-Id: I95bab9814471bb9347101d654f6dc902159f8fe3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3538670Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/main@{#80757}
-
- 25 May, 2022 26 commits
-
-
Shu-yu Guo authored
IsCompiledScope retains code to be safe against bytecode flushing, but %PrepareFunctionForOptimization isn't currently initializing it with the function's current compiled state. IOW, it's only retaining freshly compiled code and is causing flakes for already-compiled functions. Bug: v8:12697 Change-Id: Ie82a4adb8a136da708b3ae0ce27a42f5c277d324 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3668318Reviewed-by:
-
Frank Tang authored
Spec Text: https://tc39.es/proposal-temporal/#sec-date.prototype.totemporalinstant Bug: v8:11544 Change-Id: I65315152333291f76edc05cc41a528912a185d02 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3609214 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
-
Frank Tang authored
Spec Text: https://tc39.es/proposal-temporal/#sec-temporal.zoneddatetime.prototype.startofday Bug: v8:11544 Change-Id: I475e03fa9ba43290896a906524414cfbddd1f7bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3385610 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
-
Milad Fa authored
ip holds the jump table slot. Change-Id: Ia56bf62835155d58ef10e57d761088d0b9a9710d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3668285Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Farazmand <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/main@{#80753}
-
Milad Fa authored
Port 22a16bda Original Commit Message: The Runtime_WasmCompileLazy function was returning a ptr-sized address, wrapped in an Object. This worked because no GC is triggered between the return from the runtime function and the point where we jump to the returned address. In a pointer-compressed world though, generated code assumes that all objects live in the same 4GB heap, so comparisons only compare the lower 32 bit. On a 64-bit system, this can lead to collisions where a comparison determines that the returned address equals a heap object, even though the upper 32-bit differ. This happens occasionally in the wild, where the returned function entry pointer has the same lower half than the exception sentinel value. This leads to triggering stack unwinding (by the CEntry stub), which then fails (with a CHECK) because there is no pending exception. This CL fixes that by returning a Smi instead which is the offset in the jump table where the kWasmCompileLazy builtin should jump to. The builtin then gets the jump table start address from the instance object, adds the offset that the runtime function returned, and performs the jump. We do not include a regression test because this failure is very spurious and hard to reproduce. R=clemensb@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: I92907b97a9d44d8cf42bb356ef350a22f7c5d5e1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3666249 Commit-Queue: Milad Farazmand <mfarazma@redhat.com> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Manos Koukoutos authored
Bug: v8:12907 Change-Id: I8a6da86b4c88b5cfcc9bbb349841c422ac81b64e No-Tree-Checks: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3667082 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Andy Wingo authored
Bug: v8:12868 Also adds the equivalent of Utf8Decoder, but for WTF-8. Change-Id: I1548a44b0aea912cdd429eb85be4dfc606355cad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3660257Reviewed-by:
-
Dominik Inführ authored
The fast path of all write barriers already got mostly unified in https://crrev.com/c/3644964. However, the shared heap write barrier still added a new branch in the fast path of the full write barrier. This CL unifies the branch for the generational and the shared heap write barrier in the fast path at the cost of an additional branch in the slow path. This should hopefully the rest of the regressions caused by introducing the shared heap write barrier. Bug: chromium:1326446, v8:11708 Change-Id: Id5a8334c50a7455e53caf65891d4304d9d2e7702 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663091 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#80749}
-
Maya Lekova authored
The generated code checks if the receiver is a JS_API_OBJECT and if the receiver requires an access check, and if not it lowers the call to an API call. We also add compilation dependencies on the protector cell to deopt if our invariants change. (Note - the actual invalidation of these cells will be implemented in a follow up CL) Bug: v8:11321 Change-Id: I15722f1e5fac7176e292da4a35186e4609636aba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2719563 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#80748}
-
Anton Bikineev authored
Due to collections with inlined storage, Oilpan still supports on-stack Members, which are always compressed if pointer compression is enabled. This CL scans halfwords (together with full words) on stack to find potential pointers. Since on-heap pointers can only be compressed and in-construction objects always reside on heap, only halfwords need to be scanned for them. The alternative potential followup approaches: 1) Use a separate uncompressed type for pointer in inlined collections; 2) Dynamically register regions of stack containing compressed pointers. Bug: chromium:1325007 Change-Id: Ia706fd8e7383d30aff11f4014faa9edd3d289a55 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644959Reviewed-by:
-
Manos Koukoutos authored
We introduce wasm-gc specific nodes into the Turbofan IR, corresponding to the wasm opcodes: ref.as_non_null, ref.is_null, ref.null, rtt.canon, ref.test, ref.cast. We define them as simplified operators. These are lowered by a dedicated phase in the wasm pipeline. Optimizations based on these nodes will be introduced later. Note: We rename ObjectReferenceKnowledge to WasmTypeCheckConfig and move it to a separate file, as it is now used in simplified-operator as well. Bug: v8:7748 Change-Id: Iceaf04eca089b08bad794f567359196e8ba78d93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3654102Reviewed-by:
-
Dominik Inführ authored
There is now only one invocation left of MemoryAllocator::Unmapper::FreeQueuedChunks in the GC epilogue. Bug: chromium:1329064, chromium:1327132 Change-Id: Icc21ada4c5a8a9505ed6435ef1f62fe48b2dbb52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3667079 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Seth Brenith authored
This change reverts the following: 400b2cc2 Don't rescue old top-level SharedFunctionInfos Reviewed on https://chromium-review.googlesource.com/c/v8/v8/+/3657472 16a7150b Reland "Disable recompilation of existing Scripts from Isolate compilation cache" Reviewed on https://chromium-review.googlesource.com/c/v8/v8/+/3655011 2df4d58a Fix rehashing of script compilation cache Reviewed on https://chromium-review.googlesource.com/c/v8/v8/+/3654413 c8848cf4 Refactor CompilationSubCache Reviewed on https://chromium-review.googlesource.com/c/v8/v8/+/3629603 25072178 Improve Script reuse in isolate compilation cache, part 1 Reviewed on https://chromium-review.googlesource.com/c/v8/v8/+/3597106 Bug: v8:12808, chromium:1325566, chromium:1325567, chromium:1325601, chromium:1328671, chromium:1328672, chromium:1328678, chromium:1328811, chromium:1328810 Change-Id: I1d318dc172e5214166d3b15f19903186f4fe6024 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3664023Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#80744}
-
Milad Fa authored
GN is not available as a cipd package for ppc/s390 and needs to be built from source. Change-Id: I5f6eda13cd6227d20fc800cab7f54496a2d33f68 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663154Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Igor Sheludko authored
When a callback does not intercept the request 1) it should not call info.GetReturnValue().Set(), 2) it must not produce side effects. Bug: v8:12873, chromium:1310062 Change-Id: If02994f24f1a68eb96c1af7cdd6dd7109f0617c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652786Reviewed-by:
-
Simon Zünd authored
This CL fixes an issue with async stacks. The async task stack is not torn down between page navigations or reloads. The result is that any new async tasks are stacked on top of the old pages async task stack. This was not prominent until now for two reasons: 1) Async tasks created in blink are always finished as long as destructors have time to run. 2) When V8 is terminated while running the micro task queue also all async tasks created for Promises (including `await`) are cleaned up properly. Introducing the stack tagging API made it more common for having unfinished async tasks open outside the MTQ, which left the async task stack non-empty during navigation. This CL fixes this problem by clearing out all the async task and async stack data structures for a context group when that context group is reset. R=bmeurer@chromium.org, victorporof@chromium.org Fixed: chromium:1328785 Change-Id: Iee0c3c4a55f66e643829dae3726dc03c735da1dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3666620Reviewed-by: -
Darius M authored
Bug: v8:12865 Change-Id: I539a5b0a9c3c78ef9a767de75b71dd06de337d9a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647351Reviewed-by:
-
Samuel Groß authored
V8_SANDBOX has been renamed to V8_ENABLE_SANDBOX in crrev.com/c/3647355 and its remaining uses in Chromium have now been renamed as well. Bug: v8:10391 Change-Id: Ibb23ecab6687438b462685ef7fa044c0024dd098 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3660251Reviewed-by:
-
Clemens Backes authored
There were multiple fields missing from the output. R=jkummerow@chromium.org Change-Id: Ie4c3171339943414c58c2fe6f0e507cdd531dd8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3664497Reviewed-by:
-
Liu Yu authored
Port commit 22a16bda Bug: chromium:1311960 Change-Id: Id06b901e5290a0c7d2c01f4fabbb98d0f47eb570 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3665938 Auto-Submit: Liu Yu <liuyu@loongson.cn> Reviewed-by:
Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/main@{#80737}
-
Leszek Swirski authored
Add a generic DefineNamedOwn node for DefineNamedOwnProperty, and a monomorphic fast path identical to SetNamedProperty for simple field stores. Bug: v8:7700 Change-Id: I35ff9d54be8bb8e437865e4d1ba38eb726034e24 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663084 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Simon Zünd authored
This CL fixes a wrong assumption in the LiveEdit machinery. Namely the assumption that every FunctionLiteral the parser finds, will have a corresponding SFI created by the compiler. This assumption does not hold in all cases. Inner functions that are never referenced by the outer function don't get an SFI. R=bmeurer@chromium.org Fixed: chromium:1328453 Change-Id: I674f023f948954c1fcae04a4aa2afb69ea1642aa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663443 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/google_benchmark/src: https://chromium.googlesource.com/external/github.com/google/benchmark/+log/37be1e8..7eb8c0f Introduce warmup phase to BenchmarkRunner (#1130) (#1399) (Matthdonau) https://chromium.googlesource.com/external/github.com/google/benchmark/+/7eb8c0f Add support to get clock for new architecture CSKY (#1400) (Zi Xuan Wu (Zeson)) https://chromium.googlesource.com/external/github.com/google/benchmark/+/6c46c9f R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com,mlippautz@chromium.org Change-Id: Id8121e8c4d87442bde184c7c940d8b102ebdf9c0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3665706 Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#80734}
-
Andreas Haas authored
The CL https://crrev.com/c/3530115 deleted files that were referenced in the bazel build script. R=bmeurer@chromium.org Change-Id: I8e7bbcd90f7ada516209f478fe78e1437b04c697 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3664496 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Frank Tang authored
Also add AO: CompareTemporalTime Spec Text: https://tc39.es/proposal-temporal/#sec-temporal.plaintime.compare https://tc39.es/proposal-temporal/#sec-temporal.plaintime.prototype.equals https://tc39.es/proposal-temporal/#sec-temporal-comparetemporaltime Bug: v8:11544 Change-Id: I8e2a320c2e296558e1fb15ef6e855e6b6a14ece2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3538669Reviewed-by:
-
Frank Tang authored
Spec Text: https://tc39.es/proposal-temporal/#sec-temporal.plaindatetime.prototype.toplaindate https://tc39.es/proposal-temporal/#sec-temporal.plaindatetime.prototype.toplaintime Bug: v8:11544 Change-Id: Ifb7115823d1d3d1ff53806f1b376d69302e00ae1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3385761Reviewed-by:
-
- 24 May, 2022 8 commits
-
-
Frank Tang authored
Spec Text: https://tc39.es/proposal-temporal/#sec-temporal.plaintime.prototype.tozoneddatetime Bug: v8:11544 Change-Id: I147b1d21b4728520c5667a30548ec77f71d7445a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3554456Reviewed-by:
-
Clemens Backes authored
The Runtime_WasmCompileLazy function was returning a ptr-sized address, wrapped in an Object. This worked because no GC is triggered between the return from the runtime function and the point where we jump to the returned address. In a pointer-compressed world though, generated code assumes that all objects live in the same 4GB heap, so comparisons only compare the lower 32 bit. On a 64-bit system, this can lead to collisions where a comparison determines that the returned address equals a heap object, even though the upper 32-bit differ. This happens occasionally in the wild, where the returned function entry pointer has the same lower half than the exception sentinel value. This leads to triggering stack unwinding (by the CEntry stub), which then fails (with a CHECK) because there is no pending exception. This CL fixes that by returning a Smi instead which is the offset in the jump table where the kWasmCompileLazy builtin should jump to. The builtin then gets the jump table start address from the instance object, adds the offset that the runtime function returned, and performs the jump. We do not include a regression test because this failure is very spurious and hard to reproduce. R=jkummerow@chromium.org Bug: chromium:1311960 Change-Id: I5a72daf78905904f8ae8ade8630793c42e223984 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663093 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Patrick Thier authored
The underlying issue was fixed with https://crrev.com/c/3660258 Bug: v8:12883 Change-Id: If7a1fdaf122396396cfbaaae3a68ef89bafc1703 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663342 Auto-Submit: Patrick Thier <pthier@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#80728}
-
Clemens Backes authored
The Wasm C API currently disabled dynamic tiering, in order to have deterministic behaviour for serialization of Wasm modules. As dynamic tiering is now shipped, also the C API should follow. Serialization of a Wasm module now just serializes the current state, so embedders are responsible for warming up a module before serializing it. If requested, we can add an internal API to enforce full tier-up of all functions, but we will leave that for later. R=ahaas@chromium.org, jkummerow@chromium.org Bug: v8:12899 Change-Id: I55df63f0b6c1f285e4983f9f7d5fb66aa41637bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3660261Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80727}
-
Junliang Yan authored
Change-Id: Ifbfa391482215ed13954422fef028a5697ac6bb8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663149Reviewed-by:
Milad Farazmand <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/main@{#80726}
-
Junliang Yan authored
Change-Id: I25b6f6d76177394e3812ce506a06381a1afcc863 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663148Reviewed-by:
-
Junliang Yan authored
Change-Id: Ic7ac221c18f242740ae088b856d9295cd1256936 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663147Reviewed-by:
-
Leszek Swirski authored
Same pattern as Int32 compare ops. Bug: v8:7700 Change-Id: Ia090cb97d6c5c99c6aa719ec5db1a2a8e2156472 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663340Reviewed-by:
-
