- 03 Dec, 2020 26 commits
-
-
Milad Fa authored
brc or brcl may be emitted depending on the offset length. The emitted instr size may be 4 or 6 bytes. Change-Id: I542ae6a60378ee33e48e08d4f1cdeda4c4c70bb1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2572497Reviewed-by: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#71603}
-
Thibaud Michaud authored
First step towards the new exception handling proposal: https://github.com/WebAssembly/exception-handling/issues/125 This is essentially a revert of: "[wasm] Switch to new 'catch' and 'br_on_exn' proposal." The changes are: - "catch" instruction takes a tag immediate, - "rethrow" instruction takes a label immediate, - Add "catch_all" instruction, - Remove "br_on_exn" instruction, - Do not push exceptions on the stack, only the encoded values R=clemensb@chromium.org CC=aheejin@chromium.org Bug: v8:8091 Change-Id: Iea4d8d5a5d3ad50693f645e93c13e8de117aa884 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484514 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#71602}
-
Sathya Gunasekaran authored
No-Try: true Bug: v8:11222 Change-Id: I64e30e95101d0c8a318c7081b8c94f97fdb8538c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571127Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#71601}
-
Leszek Swirski authored
TurboFan creates DisallowHeapAccess scopes, to prevent heap access in the concurrent parts of the compiler. Then, for parts of the compiler that do want to access the heap, it either creates Allow* scopes (which should be avoided since they "punch a hole" in the Disallow* scopes), or relies on a weakening of Handle::IsDereferenceAllowed which allows handles owned by a LocalHeap to be dereferenced even if there is a DisallowHeapDereference scope. This patch: a) Strengthens the implicit requirements around handle dereferencing to require a running heap on this thread (either main-thread heap or an un-parked, un-safepointed LocalHeap). b) Removes the overly strict Disallow scopes in TurboFan, relying instead on implicit requirements for allocation/handle dereferencing in off-thread code. c) Cleans up the "should_disallow_heap_access" predicate to be more explicit about what should be disallowed (e.g. property accesses can't be computed concurrently) Change-Id: Icb56b7764913ac17e2db197a70bb189af88a6978 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2554617 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71600}
-
Daniel Clark authored
I'd implemented Module::GetModuleRequests() such that it can only be called on a SourceTextModuleRecord, forgetting that one of the APIs it replaces, Module::GetModuleRequestsLength(), could be called on a synthetic module. The old behavior allowed embedders to write code that iterates over a module's requests without needing to handle synthetic modules as a special case. GetModuleRequestsLength() would just return 0 for all synthetic modules and the code to process the requests would be skipped seamlessly for them. With the new GetModuleRequests() API, this would no longer be possible, and embedders would explicitly need to check IsSyntheticModule() before calling it. Thus, to reach parity with the old API, this change allows embedders to call GetModuleRequests() on a synthetic module, which will always result in an empty FixedArray. Bug: v8:10958 Change-Id: I6024261fe46d18fa7acc83b0ec8f69d6af21b28d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2570146Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71599}
-
Dominik Inführ authored
These tests are pretty slow with both TSAN and --stress-incremental-marking enabled. * Skip octane/raytrace for the variant stress when TSAN is enabled. * Test wasm/shared-memory-worker-stress is slow with TSAN. Change-Id: Ia4b8ce2986d04e6ef2fc7d28991cd5ce7faf31e5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571129Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#71598}
-
Junliang Yan authored
Change-Id: I611f5c7a41bc6d050ca36d1c011d47795bfc5abc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2570033Reviewed-by: Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#71597}
-
Junliang Yan authored
Change-Id: Ia2b9861e720cb2d2ce1d0d88867f31467798278d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569771Reviewed-by: Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#71596}
-
Manos Koukoutos authored
AnalyzeLoopAssignment did not take into account that 'let' shifts local indexes. Drive-by: Use gTest infrastructure in AnalyzeLoopAssignment tests (EXPECT_*) instead of CHECKs. Bug: v8:9495 Change-Id: Ic0ddb5edfde48acf172f4cac9bdcd0312b6121a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567955 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#71595}
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: I50476740e2e6c78aff6db859db1db86f25ce897b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569561 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#71594}
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: I108a847e12df2438cc73e4f7a31ba4148f07cdc0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569562 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#71593}
-
Dominik Inführ authored
This is a reland of 2afb00c0 Original change's description: > [heap] Remove SWEEPING phase in incremental marking > > The SWEEPING phase in incremental marking was used to finish sweeping > of the last GC cycle concurrently before starting incremental marking. > This avoids potentially long pauses when starting incremental marking. > However this shouldn't be necessary in most cases where sweeping is > already finished when starting the next cycle. The implementation also > didn't cleanly separate the GC cycles. > > In case the sweeping phase is necessary for pause times, we can > introduce a "CompleteSweep" phase which runs right before starting > incremental marking. > > Change-Id: Iaff8c06d5691e584894f57941f181d0424051eec > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567707 > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71555} Change-Id: I173bdeaf342d4c0590453f7d9eeb8ab5cfddc73c Bug: v8:11220, v8:11221 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571111 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#71592}
-
Andreas Haas authored
Safepoint maps record all spill slots that contain a tagged value. The introduction of multi-value return changed the stack frame layout though and the calculation of spill slots has not been adjusted accordingly. This CL adjusts the creation of safepoints now to work for multi-value returns as well. R=neis@chromium.org Bug: v8:11206 Change-Id: Id623dbc28b976dcf625ac78738e03e642fafbb36 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569762 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#71591}
-
Sathya Gunasekaran authored
Bug: v8:11222 Change-Id: I18a5c58315e37443de1a328ff4d254116c67fcfd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569772Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#71590}
-
Philip Pfaffe authored
Also construct the `JSMap`s used to store these names lazily and only on-demand, and construct them directly instead of first doing a `std::vector<Handle<String>>` and using that to construct the `JSMap`. The latter resulted in a gigantic root set of 150k+ handles, which wasn't well received by the GC. Bug: chromium:1154154 Fixed: chromium:1154564 Also-By: bmeurer@chromium.org Change-Id: I92e8931f15eda133e2a62b5cc53fbe1f2dafcead Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2568275 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Philip Pfaffe <pfaffe@chromium.org> Cr-Commit-Position: refs/heads/master@{#71589}
-
Liu Yu authored
Port: 360c9294 Change-Id: I9a0d0dd3d70ad6dd5aa94aa2d8f200111a9f5c3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2570828Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Auto-Submit: Liu yu <liuyu@loongson.cn> Cr-Commit-Position: refs/heads/master@{#71588}
-
Zhi An Ng authored
EncodeNeonUnaryOp and EncodeNeonSizedOp are essentially the same, they are both helpers to encode instructions in the encoding group "Advanced SIMD two registers misc". Consolidate them into a single helper. Bug: v8:11074 Change-Id: I8b0c21bfbce51de72b41cbd3d34cf4fed9ce8819 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567535 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#71587}
-
Zhi An Ng authored
This reverts commit d0f7c6a8. Reason for revert: Causing flaky tests https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20-%20debug/31929/overview Original change's description: > Reland "[wasm-simd][arm] Prototype i8x16.popcnt" > > This is a reland of e2aa734a > > The original change was speculatively reverted in > https://crrev.com/c/2568925 but seems unrelated to the flakey > test failures (which are on x64). > > Original change's description: > > [wasm-simd][arm] Prototype i8x16.popcnt > > > > Bug: v8:11002 > > Change-Id: Ib97e51ed52249a1af7a4b879396b70a016991719 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567534 > > Commit-Queue: Zhi An Ng <zhin@chromium.org> > > Reviewed-by: Bill Budge <bbudge@chromium.org> > > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#71552} > > Bug: v8:11002 > Change-Id: I714918e2640d27d29953f940e3bedeb9ea2f8a08 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567243 > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Bill Budge <bbudge@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71585} TBR=bbudge@chromium.org,jkummerow@chromium.org,v8-arm-ports@googlegroups.com,zhin@chromium.org Change-Id: Ib8454a4c20937495c2b83b7ceb3ad594b1b9e7e5 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:11002 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569559Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71586}
-
Zhi An Ng authored
This is a reland of e2aa734a The original change was speculatively reverted in https://crrev.com/c/2568925 but seems unrelated to the flakey test failures (which are on x64). Original change's description: > [wasm-simd][arm] Prototype i8x16.popcnt > > Bug: v8:11002 > Change-Id: Ib97e51ed52249a1af7a4b879396b70a016991719 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567534 > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Reviewed-by: Bill Budge <bbudge@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71552} Bug: v8:11002 Change-Id: I714918e2640d27d29953f940e3bedeb9ea2f8a08 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567243 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#71585}
-
Zhi An Ng authored
It doesn't seem to be a problem at all, I think we already have SSE4_1 scope enabled somewhere. Change-Id: I501166a4e45214832e85df8a2594dabe6976bfd3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567191Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71584}
-
Liu Yu authored
Port commit 7730fd94 Bug: v8:10582 Change-Id: I2597bbbbe06ba16dba042ee512119822305a5f70 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2570433Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/master@{#71583}
-
Manos Koukoutos authored
br_on_null should push a value on the stack, even in unreachable code. Bug: v8:9495 Change-Id: Ic227c2f889b863a267a7ff5f33e539b43e66b42f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567966Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#71582}
-
Zhi An Ng authored
These instructions have the same implementation in code-generator. Bug: v8:11217 Change-Id: I06fa7eaf6360aa8f142ee1d0b36832be3a518b7b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2568920Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71581}
-
Zhi An Ng authored
Movddup can take a memory operand, so we can save a move from gp reg to xmm reg in that case. No problem with unaligned memory since we are loading 64 bits (not 128 bits). Also drive-by comment on i32x4.splat, it uses pshufd, which can also take a memory operand (saving a mov), but we need aligned memory for that first. Bug: v8:9198 Change-Id: I55969888db1debb6ed4d193f767589d0da598386 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567538Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71580}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/6ca160d..cb1a537 Rolling v8/third_party/aemu-linux-x64: DQxYsB8PVOoG7iQxYf01AM0DSgvbu3DKEyrTvcT79zAC..h_lfZjWg21ZL3JBJXSabJsKCnyhbzTyNAISwoJCfLCAC Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/80cea4f..4640dfb TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I58bf8af05b8da06afc1f2d57935edbd6769ba343 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2570432Reviewed-by: 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/master@{#71579}
-
Junliang Yan authored
Change-Id: I8ec751f578e2d7a790852670690797f19aba74e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2570220Reviewed-by: Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#71578}
-
- 02 Dec, 2020 14 commits
-
-
Junliang Yan authored
Cleanup Memcpy and use get/set_simd_register_by_lane Change-Id: Icbdd838e075d93d75064bd8e47eb95c02f1da9d4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2568589 Commit-Queue: Junliang Yan <junyan@redhat.com> Reviewed-by: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#71577}
-
Junliang Yan authored
Change-Id: Ia92e1e85aa19abb8cc0f756e5334a539cf604287 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2570135Reviewed-by: Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#71576}
-
Milad Fa authored
Due to the lane numbering difference between Intel and IBM machines, we need to switch the input registers when doing a vector pack. Change-Id: Id01d6292cb2a65b78dccdf3bab1d5ff010e1d018 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569996Reviewed-by: Junliang Yan <junyan@redhat.com> Reviewed-by: Milad Fa <mfarazma@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#71575}
-
Milad Fa authored
Port 7730fd94 Original Commit Message: Unifies various operators for dynamic map checks with the naming scheme of DynamicCheckMaps (to be similar to CheckMaps. R=rmcilroy@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG=v8:10582 LOG=N Change-Id: I0c7665eb5ec3cd0b0b8217af3ec8e9e18a3d3055 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569593Reviewed-by: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#71574}
-
Santiago Aboy Solanes authored
Concurrently accessing internal external uncached strings is not thread-safe. We are removing a case where we can make such a string through MakeExternal. Bug: v8:7790 Change-Id: I958062c15cf40ccc330600bb572de98620866e54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565511 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#71573}
-
Manos Koukoutos authored
read_heap_type did not have knowledge of the module for which the heap type was being decoded. As a result, callers of read_heap_type (or read_value_type, which in turn calls read_heap_type) had to check after the fact that a decoded indexed type (ref, ref null, or rtt) references a type index within the module's bounds. This was not done consistently, and was missing (at least) in DecodeLocals. To avoid such problems in the future, this CL refactors read_heap_type to accept a module and check the decoded index against it. Changes: - Add WasmModule argument to read_heap_type. Do so accordingly to all its transitive callers (read_value_type, immediate arguments, DecodeLocalDecls, DecodeValue/HeapType in unittests). - Add index check to read_heap_type and emit an error for an out-of-bounds index. - Remove all other now-redundant index validations. Replace them with decoder->ok() if needed (since read_heap_type will now emit an error). - Fix error message in Validate for BlockTypeImmediate. - In DecodeLocalDecls in unittests, pass an empty module to DecodeLocalDecls in the main code. - Add a unit test with an invalid index in local type declarations. Bug: v8:9495 Change-Id: I4ed1204847db80f78b6ae85fa40d300cd2456295 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569757Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#71572}
-
Milad Fa authored
Port b6643320 Original Commit Message: In order to reduce the codegen size of dynamic map checks, add the ability to have an eager with resume deopt point, which can call a given builitin to perform a more detailed check than can be done in codegen, and then either deoptimizes itself (as if the calling code had performed an eager deopt) or resumes execution in the calling code after the check. In addition, support for adding extra arguments to a deoptimization continuation is added to enable us to pass the necessary arguments to the DynamicMapChecks builtin. Finally, a trampoline is added to the DynamicMapChecks which saves the registers that might be clobbered by that builtin, to avoid having to save them in the generated code. This trampoline also performs the deoptimization based on the result of the DynamicMapChecks builtin. In order to ensure both the trampoline and DynamicMapChecks builtin have the same call interface, and to limit the number of registers that need saving in the trampoline, the DynamicMapChecks builtin is moved to be a CSA builtin with a custom CallInterfaceDescriptor, that calls an exported Torque macro that implements the actual functionality. All told, this changes the codegen for a monomorphic dynamic map check from: movl rbx,<expected_map> cmpl [<object>-0x1],rbx jnz <deferred_call> resume_point: ... deferred_call: <spill registers> movl rax,<slot> movq rbx,<object> movq rcx,<handler> movq r10,<DynamicMapChecks> call r10 cmpq rax,0x0 jz <restore_regs> cmpq rax,0x1 jz <deopt_point_1> cmpq rax,0x2 jz <deopt_point_2> int3l restore_regs: <restore_regs> jmp <resume_point> ... deopt_point_1: call Deoptimization_Eager deopt_point_2: call Deoptimization_Bailout movl rcx,<expected_map> movq rdx,<handler> cmpl [<object>-0x1],rcx jnz <deopt_point> resume_point: ... deopt_point: call DynamicMapChecksTrampoline jmp <resume_point> R=rmcilroy@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG=v8:10582 LOG=N Change-Id: I0739c1b40ed06bb22b73ebe1833ea648b540882a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569359Reviewed-by: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#71571}
-
Dominik Inführ authored
This reverts commit 2afb00c0. Reason for revert: Some tests started to timeout. Original change's description: > [heap] Remove SWEEPING phase in incremental marking > > The SWEEPING phase in incremental marking was used to finish sweeping > of the last GC cycle concurrently before starting incremental marking. > This avoids potentially long pauses when starting incremental marking. > However this shouldn't be necessary in most cases where sweeping is > already finished when starting the next cycle. The implementation also > didn't cleanly separate the GC cycles. > > In case the sweeping phase is necessary for pause times, we can > introduce a "CompleteSweep" phase which runs right before starting > incremental marking. > > Change-Id: Iaff8c06d5691e584894f57941f181d0424051eec > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567707 > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71555} TBR=ulan@chromium.org,dinfuehr@chromium.org Change-Id: I9adea60c21ff7cdfa7bbac3e6a4a240640fa5ea9 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569766Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#71570}
-
Maya Lekova authored
This reverts commit 3238162d. Reason for revert: Speculative revert for https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64/40411/overview, causing SEGV_ACCERR on test/mjsunit/harmony/promise-any-overflow-2.js and other failures in minor_mc variant Original change's description: > Reland "[heap] Add epoch to GC tracing events" > > This is a reland of be52501d > > Fix data race by not emitting the epoch for sweeper background jobs > at them moment. > > Original change's description: > > [heap] Add epoch to GC tracing events > > > > This CL adds the TRACE_GC_EPOCH macro, which adds the epoch as attribute > > to the trace event. Use TRACE_GC_EPOCH for top-level events, nested > > events can get the information from its parent. > > > > V8's GC needs an epoch for young and full collections, since scavenges > > also occur during incremental marking. The epoch is also process-wide, > > so different isolates do not reuse the same id. > > > > Change-Id: I8889bccce51e008374b4796445a50062bd87a45d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565247 > > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#71521} > > Change-Id: Ib8f4bfdc01c459955eb6db63bb6e24a8aa068f09 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567702 > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71567} TBR=ulan@chromium.org,dinfuehr@chromium.org Change-Id: I29a131f798c3536d16e4b4c44c0fcb8b35dd0051 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569764Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#71569}
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: Ifdd52d501a1d55a2fe176f0995f8c0e7f71ca1fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569131 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#71568}
-
Dominik Inführ authored
This is a reland of be52501d Fix data race by not emitting the epoch for sweeper background jobs at them moment. Original change's description: > [heap] Add epoch to GC tracing events > > This CL adds the TRACE_GC_EPOCH macro, which adds the epoch as attribute > to the trace event. Use TRACE_GC_EPOCH for top-level events, nested > events can get the information from its parent. > > V8's GC needs an epoch for young and full collections, since scavenges > also occur during incremental marking. The epoch is also process-wide, > so different isolates do not reuse the same id. > > Change-Id: I8889bccce51e008374b4796445a50062bd87a45d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565247 > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71521} Change-Id: Ib8f4bfdc01c459955eb6db63bb6e24a8aa068f09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567702 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#71567}
-
Manos Koukoutos authored
If DecodeLocals exits early, num_locals_ is left in an inconsistent state. This CL fixes this issue by updating num_locals_ as the local_types_ are updated. Bug: chromium:1154439 Change-Id: I02328a050df8b2827a42f59443e994f535d3c826 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567954Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#71566}
-
Camillo Bruni authored
- Don't print normalize transition for cached maps - Avoid printing two transitions in Map::CopyReplaceDescriptor - Harden processor.mjs existing existing broken logs by skipping double entries and avoiding mutliple edges to the same target map Bug: v8:10644 Change-Id: I561a0f888c8835a40a289baa50d65ff69e368bad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565123Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#71565}
-
Clemens Backes authored
The {ParallelRegisterMove} at the end of {AtomicLoad} might need a temporary scratch register for spilling values to the stack. Make sure that one is available by giving up the scratch register used for the address of the atomic access. R=ahaas@chromium.org Bug: chromium:1153442 Change-Id: I267c43e2193662c420f96f6683ebd4bbb0e1bca3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566759Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#71564}
-