- 24 Feb, 2022 1 commit
-
-
Leszek Swirski authored
Maglev is mid-tier optimising compiler designed mainly for compilation speed that can still generate good code for straightforward JS. This initial commit is an MVP for Maglev which can compile and run some very simple code, and sets up a framework that we can build upon. Design: https://docs.google.com/document/d/13CwgSL4yawxuYg3iNlM-4ZPCB8RgJya6b8H_E2F-Aek/edit# Bug: v8:7700 Change-Id: I5ae074ae099126c2c0d50864ac9b3d6fa5c9e85a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3483664Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79247}
-
- 23 Feb, 2022 1 commit
-
-
Jakob Gruber authored
A collection of smallish cleanups and improvements for safepoints. Maintainability: - The class names were not very clear; move Safepoint inside SafepointTableBuilder to clarify that this wrapper class is used during codegen. - Rename DefinePointerSlot/DefineRegister to DefineTaggedStackSlot/DefineTaggedRegister for clarity. - Use named constants instead of -1. - DefineTaggedRegister has no connection to kNoDeoptIndex, remove the DCHECK and comment. - Remove the unused kNumSafepointRegisters constant + other dead code. - Small clarifications in CommonFrame::IterateCompiledFrame. - Rename has_safepoint_info to uses_safepoint_table and refactor s.t. `stack_slots` can be used when `uses_safepoint_table == false`. In this case it just returns 0. Perf: - During codegen, represent stack slots as a growable bit vector instead of a list of int indices. Extend GrowableBitVector functionality to support the above. - Track the minimum index instead of iterating all stack slots in all safepoints before encoding. Bug: v8:7700 Change-Id: If409bc42c825d47fc0074fce51e3b963fd080806 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3483659Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79233}
-
- 21 Feb, 2022 2 commits
-
-
Leszek Swirski authored
This reverts commit 9f902b74. Reason for revert: Reverting due to various fuzzing issues (numfuzz issues listed in original CL comments, ochang fuzzer in https://bugs.chromium.org/p/chromium/issues/detail?id=1299418) Original change's description: > [turbofan] Making OSR concurrent > > ... to reduce compilation overhead on the main thread for OSR > > Bug: v8:12161 > Change-Id: I54ca5fa6201405daf92dac9cf51d5de4b46577b3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3369361 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> > Cr-Commit-Position: refs/heads/main@{#79188} Bug: v8:12161 Change-Id: Id6f6086517cd77fb1aa60b20fd03528b8e2ca686 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3477104 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79194}
-
Fanchen Kong authored
... to reduce compilation overhead on the main thread for OSR Bug: v8:12161 Change-Id: I54ca5fa6201405daf92dac9cf51d5de4b46577b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3369361Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Cr-Commit-Position: refs/heads/main@{#79188}
-
- 10 Feb, 2022 1 commit
-
-
Igor Sheludko authored
This CL 1) adds relaxed version of CodeDataContainer::code_cage_base accessors and use them from relaxed CodeDataContainer::code accessors, 2) uses relaxed version of FromCodeT() in JSFunctionRef::code(). Bug: v8:11880, chromium:1293642 Change-Id: Idc9ba59a97a44a0963197cad50b5e5b440f9629e Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3450423Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Auto-Submit: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#79030}
-
- 07 Feb, 2022 1 commit
-
-
Igor Sheludko authored
Drive-by: cleanup accessor declaration and definition macros. Bug: v8:11880, v8:12596 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Change-Id: Ia04a7f21d911386e610f963f55cbc1d310b2f442 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3439917Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78972}
-
- 31 Jan, 2022 1 commit
-
-
Benedikt Meurer authored
Previously we'd predict exceptions thrown in [[Reject]] handlers as always caught (by PromiseRejectReactionJob), but that's not what is actually specified in ECMAScript. The PromiseRejectReactionJob will turn any exception thrown into a promise rejection just like we do in the case of PromiseFulfillReactionJob, and so the catch prediction should match that behavior. Fixed: chromium:1290861 Change-Id: Id992708b009666da7c6bf1b6e3cf30752ca0a227 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3423775 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/main@{#78864}
-
- 20 Jan, 2022 1 commit
-
-
Jakob Gruber authored
Bug: v8:12552 Change-Id: I99e4d8e8aeba5460f11e54cc1b2bcaea98a5276d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400964Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#78698}
-
- 16 Dec, 2021 1 commit
-
-
Igor Sheludko authored
... in order to avoid Code <-> CodeT conversions in builtins. This CL changes the meaning of RelocInfo::CODE_TARGET which now expects CodeT objects as a code target. In order to reduce code churn this CL makes BUILTIN_CODE and friends return CodeT instead of Code. In the follow-up CLs BUILTIN_CODET and friends will be removed. Bug: v8:11880 Change-Id: Ib8f60973e55c60fc62ba84707471da388f8201b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338483Reviewed-by:
Patrick Thier <pthier@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78393}
-
- 14 Dec, 2021 4 commits
-
-
Igor Sheludko authored
This CL migrates the following objects' APIs to CodeT: * WasmFunctionData, * WasmInternalFunction. Bug: v8:11880 Change-Id: Ib3f0eb41894cbd3c6b30430c4e5616eb45fbbaec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338701Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78377}
-
Igor Sheludko authored
This CL * migrates FeedbackVector::optimized_code to CodeT, * migrates OSROptimizedCodeCache to CodeT. Bug: v8:11880 Change-Id: I2082412fb9fdf90e7ed90f4454ecf55f4f3d53d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3330468Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78367}
-
Igor Sheludko authored
This CL migrates JSFunction's code accessors to CodeT. Bug: v8:11880 Change-Id: I8cf367eb79cc1d59548dd4f3e18c010f76f101cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3330466Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78365}
-
Igor Sheludko authored
Drive-by: fix TSAN issue. Bug: v8:11880 Change-Id: I8a31391c6a1855a20a243eb740e4e3e1223ecbbf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3333930Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78360}
-
- 30 Nov, 2021 2 commits
-
-
Igor Sheludko authored
This will allow making HeapObject::IsBlah() checks faster when external code space is enabled. Bug: v8:11880 Change-Id: I68473ba88063c555c90330c9748462adeb35aa0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308797Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78156}
-
Igor Sheludko authored
This will allow making HeapObject::IsBlah() checks faster when external code space is enabled. Bug: v8:11880 Change-Id: Ibee4e19859c23f11316e3cfd7961f58d8e58240a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3301478 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#78153}
-
- 18 Nov, 2021 2 commits
-
-
Jakob Gruber authored
Refactor s.t. we now compact the DependentCode weak fixed array both when adding new entries and when marked for deopts. Bug: v8:12397 Change-Id: I842f3369644e88cc0b98a1f1371259c920cc8bbf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3291320 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77973}
-
Jakob Gruber authored
Prior to this CL we regularly generated high counts of code dependencies, and installation was not the most efficient. This CL 1) implements early dependency deduplication and 2) simplifies the way dependencies are persisted on the heap through DependentCode. Re 1): we dedupe twice, once based on the CompilationDependency contents, and again once we know the final target object. Re 2): Instead of a linked list of weak fixed arrays per dependency group, store deps in a flat array together with a bitset of their dependency groups. See also: https://docs.google.com/document/d/1B34S1s3Iv6hbquZ93RugD0b-ZKfHEptJ8Fk_YyOvjDk/edit Bug: v8:12195,v8:12397 Change-Id: I9ab47f6d87b10558194b5de30a36b1122f7e362a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283074Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77969}
-
- 11 Nov, 2021 1 commit
-
-
Seth Brenith authored
My previous change https://crrev.com/c/3160299 introduced a runtime CHECK that crashes the process if V8 attempts to read a deoptimization literal which has been cleared. That CHECK is indeed crashing the process. It appears that the trouble arises in cases where the deoptimization data indicates that an object should be materialized as needed. In those cases, one of the deoptimization literals is the Map to use when materializing the object. It is possible to reach a part of the code that requires the materialized object, and therefore the Map, without there being any other owner of that Map. This is in contrast to most other deoptimization literals, which are logically equivalent to omitted values from the stack frame and therefore can't be reached without a real owner somewhere to keep them alive. To fix, I propose referring to Maps strongly from the deoptimization literals. The cases I investigated in v8:4578 didn't involve Maps, so I believe that the observed memory leaks are still fixed with this change. Bug: chromium:1268681, chromium:1268683, chromium:1268825, v8:12300 Change-Id: Ifd32a7f9cc29e0384650013ab16e05646bf57895 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272880 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77857}
-
- 09 Nov, 2021 1 commit
-
-
Seth Brenith authored
The GC already treats some embedded object pointers in Code as weak, based on Code::IsWeakObject. If one of those embedded objects ends up unmarked during a full mark-collect GC, then the Code is marked for lazy deoptimization and the embedded objects are cleared. However, many of those same objects are often held strongly by the deoptimization literal array for the Code, which causes memory leaks. This change updates the deoptimization literals array to store those objects weakly. Any Code currently executing on the stack might need those deoptimization literals in order to deoptimize, so the deoptimization literal array is marked strongly in that case. Design document: https://docs.google.com/document/d/1gFRBYCeqz9Mysx8CVYQkldBbk3AZLo8UX0DMLZV_7qw/edit?usp=sharing Bug: v8:4578 Change-Id: I02e86683c59371e9f88ecf523750c9c6afebdb39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160299Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77805}
-
- 08 Nov, 2021 1 commit
-
-
Igor Sheludko authored
This CL * adds forwarding accessors to CodeDataContainer for certain widely used Code object's fields and predicates, * adds JSFunction::set_code() overloads accepting CodeT values, * migrates SharedFunctionInfo getters to CodeT, * migrates InterpreterData::interpreter_trampoline to CodeT. Drive-by-fix: replace #if V8_EXTERNAL_CODE_SPACE with #ifdef to be consistent. Bug: v8:11880 Change-Id: I1e114076a0568068038ca6f70a86431a3a9cfb9f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3262716 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#77762}
-
- 18 Oct, 2021 3 commits
-
-
Victor Gomes authored
This is a reland of 0c459ff5 Original change's description: > [baseline] Concurrent Sparkplug n-thread with synchronised queue > > Installation in the main thread. > Design doc: https://docs.google.com/document/d/1GmEiEt2VDmhY_Ag0PiIcGWKtvQupKgNcMZUvgpfQksk/edit?resourcekey=0-seYa-QJsx1ZbjelluPG1iQ > > Change-Id: Ifc6eccd44efdf377320c64cf9957c6060334e543 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186831 > Commit-Queue: Victor Gomes <victorgomes@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77431} Change-Id: I4ea8f3c026a0a448afcb16f57517ee75cedaf83f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229379 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#77437}
-
Leszek Swirski authored
This reverts commit 0c459ff5. Reason for revert: breaks build on M1 (where W^X flag is RO) https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release%20builder/6999/overview Original change's description: > [baseline] Concurrent Sparkplug n-thread with synchronised queue > > Installation in the main thread. > Design doc: https://docs.google.com/document/d/1GmEiEt2VDmhY_Ag0PiIcGWKtvQupKgNcMZUvgpfQksk/edit?resourcekey=0-seYa-QJsx1ZbjelluPG1iQ > > Change-Id: Ifc6eccd44efdf377320c64cf9957c6060334e543 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186831 > Commit-Queue: Victor Gomes <victorgomes@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77431} Change-Id: I45a952aacf0ad29ebb703a742fdc6da7b0b7c826 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229378 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#77433}
-
Victor Gomes authored
Installation in the main thread. Design doc: https://docs.google.com/document/d/1GmEiEt2VDmhY_Ag0PiIcGWKtvQupKgNcMZUvgpfQksk/edit?resourcekey=0-seYa-QJsx1ZbjelluPG1iQ Change-Id: Ifc6eccd44efdf377320c64cf9957c6060334e543 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186831 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#77431}
-
- 11 Oct, 2021 2 commits
-
-
Igor Sheludko authored
... which will be used for decompressing Code <-> CDC references when external code space is enabled. Bug: v8:11880 Change-Id: I142f635c7cc91cdb79ed51755271fad0223ade0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3208814 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#77320}
-
Victor Gomes authored
Compiling Sparkplug on the heap saved 10% of the CompileBaseline RCS metric, but that came with too much code complexity. Since in the end that corresponds to < 1% of the entire compilation time, we decided to revert this project. This reverts: commit e29b2ae4 commit d1f2a83b commit 4666e182 commit a1147408 commit e0d4254f commit 9ab8422d commit a3b24ecc commit 1eb87706 commit fe5c9dfd commit 7ac3b55a commit 7e95f30e commit 323b5962 commit 6bf0b704 commit e82b368b commit 5020d83e commit 642a4673 commit ec7b99d5 commit fb4f89ae commit 208854bb commit 63be6dde Bug: v8:12158 Change-Id: I9f2539be6c7d80c6e243c9ab173e3c5bb0dff97d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3136453 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#77319}
-
- 06 Sep, 2021 1 commit
-
-
Leszek Swirski authored
Remove the BaselineData intermediate structure for baseline code, and write the baseline Code object into the SharedFunctionInfo directly. We still need a pointer to the BytecodeArray/InterpreterData, so re-use the Code object's deoptimization data slot for this (baseline code doesn't have deoptimization data). A consequence of this is that the BytecodeArray pointer becomes immutable when there is baseline code. This means that we cannot install a debug BytecodeArray while baseline code is active (we have to flush it first), and we can't tier-up code with debug BytecodeArray to baseline. Change-Id: I53b93ec4d4c64b833603d7992f246982fcd97596 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3118548 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#76675}
-
- 01 Sep, 2021 1 commit
-
-
Hao Xu authored
This is a reland of commit 40af03b8 The original CL failed one test in Windows, and this CL fix this issue. Original changes's description: > [codegen] Align the code start at 64 byte in x64 > > In order to make loop header aligned at 64 byte (relative to memory address), code start should also be aligned at 64 byte. > > Bug: chromium:1231471 > Change-Id: I95390babd9cc78492e0beb0f1b03901eb481d5d5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094167 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Hao A Xu <hao.a.xu@intel.com> > Cr-Commit-Position: refs/heads/main@{#76484} Bug: chromium:1231471 Change-Id: Ia927305c792c7486588bc15e9e87840d6db18478 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3133957Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Hao A Xu <hao.a.xu@intel.com> Cr-Commit-Position: refs/heads/main@{#76617}
-
- 25 Aug, 2021 2 commits
-
-
Leszek Swirski authored
This reverts commit 40af03b8. Reason for revert: Breaks on win https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20debug/39151/overview Original change's description: > [codegen] Align the code start at 64 byte in x64 > > In order to make loop header aligned at 64 byte (relative to memory address), code start should also be aligned at 64 byte. > > Bug: chromium:1231471 > Change-Id: I95390babd9cc78492e0beb0f1b03901eb481d5d5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094167 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Hao A Xu <hao.a.xu@intel.com> > Cr-Commit-Position: refs/heads/main@{#76484} Bug: chromium:1231471 Change-Id: I93ad896d40e8bb906a05eab8e03980ce2061b9c0 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3118005 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Owners-Override: 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/main@{#76488}
-
Hao Xu authored
In order to make loop header aligned at 64 byte (relative to memory address), code start should also be aligned at 64 byte. Bug: chromium:1231471 Change-Id: I95390babd9cc78492e0beb0f1b03901eb481d5d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094167Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Hao A Xu <hao.a.xu@intel.com> Cr-Commit-Position: refs/heads/main@{#76484}
-
- 16 Aug, 2021 1 commit
-
-
Yu Yin authored
Bug: v8:12008 Change-Id: I2e1d918a1370dae1e15919fbf02d69cbe48f63bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3089095Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76308}
-
- 12 Aug, 2021 1 commit
-
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I4e25140a83a0ce851195e274a489ac13cacdf676 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3086477Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#76253}
-
- 11 Aug, 2021 1 commit
-
-
Nico Hartmann authored
When running d8 with --trace-deopt, any deopt will contain the id of the node that caused this deopt. These ids also show up in the deoptimization data table of when using --print-opt-code. Change-Id: I412ca7a4ff20427100fa63101d78ee3846569a8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024144Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#76220}
-
- 20 Jul, 2021 1 commit
-
-
Seth Brenith authored
Most Torque-defined extern classes already use @generateCppClass. As Nico pointed out in [1], it would be nice to convert the remaining classes and remove this option. This change converts most of those remaining classes. I know that the future of Torque-defined classes is a subject of some debate right now, but I think that it's worth doing a few mechanical changes to reduce the existing variety of options. Changes that don't exactly follow the usual pattern: 1. BigIntBase, MutableBigInt: we can define these without a body, and then Torque treats them as "really external" rather than "kind of external, but with some Torque-generated parts". 2. RegExpMatchInfo: moved its inline functions into a separate file, which the generated -tq.cc file requires. [1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit# Bug: v8:8952 Change-Id: I84c7958a295caa0bab847683c05022e18c921cad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027742Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#75817}
-
- 19 Jul, 2021 2 commits
-
-
Seth Brenith authored
I've noticed a few places where class fields as defined in Torque have different names than the corresponding accessors in the C++ class. I think they should match. Most of this change is just mechanically updating the various places that use k##Field##Offset for those fields. Change-Id: I8ba52aed7f6a1cd6b2d71158f71150b66c2c0da0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027263 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#75796}
-
Igor Sheludko authored
... for visiting slots containing pointers to Code objects when external code space mode is enabled. These slots will require different handling once the code space is moved out of the V8 heap cage. This CL also introduces IsValidCodeObject() predicate similar to IsValidHeapObject() for checking if given HeapObject is a valid Code object. Tbr: cbruni@chromium.org Bug: v8:11880 Change-Id: I430940f4503cebfd2a6d387e44349810991a93e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3032085Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75787}
-
- 08 Jul, 2021 1 commit
-
-
Victor Gomes authored
Adds a verification step when we're compiling on heap. Bug: v8:11872 Change-Id: Ic71dc2b54e667ed4d5d861b4b9c1e1c2362f9821 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013936 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#75630}
-
- 06 Jul, 2021 1 commit
-
-
Dominik Inführ authored
This CL adds support for updating code objects. So far code objects were immutable. Sparkplug makes compilation a very frequent operation and thus wants to avoid copying the instruction stream from the AssemblerBuffer into the code object (with more overhead that entails). The idea is to allocate an "empty" Code object initially, which is likely large enough to hold the full instruction stream. Then Sparkplug will compile the given function and write the instruction stream directly into the code object. After compilation is done Sparkplug trims the Code to the right size and finishes its initialization. We use relocation_info to determine whether a Code object is fully initialized: undefined means that this object is filled by SparkPlug at the moment. If it's a proper ByteArray, this code object is assumed to be initialized. Turbofan still fully initializes the Code object immediately. Before changing the size of the code object, EnsureSweepingCompleted() makes sure that the code object's page is swept already. This prevents that the concurrent sweeper loads the new and smaller object size and stores that memory in the free list. NotifyCodeObjectChanged() signals the GC that the code object is now fully initialized and revisits that object (even if it is black already) to find and record outgoing references in the instruction stream. Design doc: https://docs.google.com/document/d/12LHGkRXY1H3IFMBrdxs2vhgtG9bfJTdquQUsX1oPoSE/edit?usp=sharing Bug: v8:11872 Change-Id: Ie1b95b27842eea5ec7e9d345052585a27d6ea7f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999087 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#75582}
-
- 28 Jun, 2021 1 commit
-
-
Igor Sheludko authored
Bug: v8:11880 Change-Id: Ief047a62b7c9323fba8b7c2e4a3200a6db7e04c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992709 Commit-Queue: Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75410}
-
- 22 Jun, 2021 1 commit
-
-
Victor Gomes authored
1. Adds the flag --sparkplug-on-heap 2. Creates OnHeapAssemblerBuffer 3. Generates code on heap (but still relocates later) 4. Provides Assembler::IsOnHeap function Bug: v8:11872 Change-Id: I6223bf27a5fbcfb5f94f3462b951443b35273661 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949097 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#75291}
-
- 18 Jun, 2021 1 commit
-
-
Igor Sheludko authored
In order to avoid unnecessary conversions to CodeT and back this CL: - makes compiler::CompileCWasmEntry() return CodeT, - makes Execution::CallWasm() accept CodeT. Bug: v8:11880 Change-Id: Ic4b7b5f476c6efcfca4bc116ecd45cdee9f0c6c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2971743Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75247}
-