- 08 Dec, 2021 26 commits
-
-
Dominik Inführ authored
Initial support for global safepoints kept it simple by entering a safepoint for each of them one after another. This means time-to-global-safepoint is the sum of all time-to-safepoint operations. We can improve this slightly by splitting up the safepoint iteration into two operations: 1) Initiate safepoint lock (locks local_heaps_mutex_, arms the barrier and sets SafepointRequested flag for all client threads) 2) Block until all runnning client threads reach a safepoint We now perform operation 1) for all clients first and only then start with operation 2). Bug: v8:11708 Change-Id: Iaafd3c6d70bcf7026f722633e9250b04148b3da6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310910Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#78308}
-
Leszek Swirski authored
Deleting / deallocating Jobs, along with everything they own (e.g. PersistentHandles), can take a long time, especially if the allocator isn't too friendly to deallocating on a different thread than where the allocation happened. Instead, enqueue Jobs for deletion as part of background processing, with the hope that they end up being deallocated on the same thread as they were allocated, and at the very least taking the deallocation time off the main thread. The deletion queue is processed after the pending background jobs are all processed, and counts as a single "background job" as far as parallelism is concerned. Bug: chromium:1275157 Change-Id: Ie7c3f725f7e510b4325e7590e60477338c478388 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314835Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78307}
-
Toon Verwaest authored
This ensures that the unhandledrejection callback fires. Bug: chromium:1219363 Change-Id: I184a728105863f9e207a603f2d45e26393c98796 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322978 Auto-Submit: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#78306}
-
Leszek Swirski authored
Change the off-thread parse to fill a SmallVector<UseCounterFeature, 8> on the BG compile task, rather than an int[kUseCounterFeatureCount] array. This allows us to keep the loop over use counts in the compile task finalization short by avoiding looping over unused counters. The value 8 was chosen as a "reasonable small number"; experimenting on our benchmarks shows a max of 3 use counts collected per compile (and at a vanishingly low percentage of all compiles). Passing around an explicit SmallVector<UseCounterFeature, 8> pointer, complete with size, is a bit ugly, but since it's used only in this one place (Parser -> BackgroundCompileTask) I can live with it to avoid further indirections. Typedeffing it is possible, but it's not clear where, since it's needed in both src/codegen/compiler.h and src/parsing/parser.h, and neither includes the other. Change-Id: Idb73e2f56fa9e8911ea29fb810d7562246f19d46 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318662Reviewed-by:
-
Andreas Haas authored
With the existing code, V8's --wasm-dynamic-tiering flag gets ignored in Chrome, because a Chrome flag would override it. With this CL, the flag --wasm-dynamic-tiering can be used to enable dynamic tiering explicitly. R=jkummerow@chromium.org Bug: v8:12281 Change-Id: I83b8417527872a1a920fcb543932915caf1ed754 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322766Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#78304}
-
Milad Fa authored
scratch is already being initialized to avoid overwriting offset_reg. We will need to use it instead of ip. Change-Id: I4ffb93341f64dd8520e2409d6a28783738627ca2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322977Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Farazmand <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/main@{#78303}
-
Leszek Swirski authored
Reduce the enqueuing cost of compiler-dispatcher jobs by getting rid of the sets and hashmaps, and instead: 1. Turning the pending job set into a queue, and 2. Making the SharedFunctionInfo's UncompiledData hold a pointer to the LazyCompilerDispatcher::Job, instead of maintaining an IdentityMap from one to the other. To avoid bloating all UncompiledData, this adds two new UncompiledData subclasses, making it four subclasses total, for with/without Preparse data and with/without a Job pointer. "should_parallel_compile" FunctionLiterals get allocated an UncompiledData with a job pointer by default, otherwise enqueueing a SFI without a job pointer triggers a reallocation of the UncompiledData to add a job pointer. Since there is no longer a set of all Jobs (aside from one for debug-only), we need to be careful to manually clear the Job pointer from the UncompiledData whenever we finish a Job (whether successfully or by aborting) and we have to make sure that we implicitly can reach all Jobs via the pending/finalizable lists, or the set of currently running jobs. Change-Id: I3aae78e6dfbdc74f5f7c1411de398433907b2705 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314833Reviewed-by: -
Marja Hölttä authored
Especially bazel requires it. No-Try: true Change-Id: I1e9bfc705601492fff4690e76692b9271070d065 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322932Reviewed-by:
-
Camillo Bruni authored
The explicit state_ variable is used to prevent undefined behaviour by double-joining the worker thread. Bug: chromium:1276382 Change-Id: I338cfdb4a587eb57fec5a5a28b42371584c99102 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318669Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#78300}
-
Joyee Cheung authored
Previously, since the source code for the synthetic class instance member initializer function was recorded as the span from the first initializer to the last initializer, there was no way to reparse the class and recompile the initializer function. It was working for most use cases because the code for the initializer function was generated eagarly and it was usually alive as long as the class was alive, so the initializer wouldn't normally be lazily parsed. This didn't work, however, when the class was snapshotted with v8::SnapshotCreator::FunctionCodeHandling::kClear, becuase then we needed to recompile the initializer when the class was instantiated. This patch implements the reparsing so that these classes can work with FunctionCodeHandling::kClear. This patch refactors ParserBase::ParseClassLiteral() so that we can reuse it for both parsing the class body normally and reparsing it to collect initializers. When reparsing the synthetic initializer function, we rewind the scanner to the beginning of the class, and parse the class body to collect the initializers. During the reparsing, field initializers are parsed with the full parser while methods of the class are pre-parsed. A few notable changes: - Extended the source range of the initializer function to cover the entire class so that we can rewind the scanner to parse the class body to collect initializers (previously, it starts from the first field initializer and ends at the last initializer). This resulted some expectation changes in the debugger tests, though the initializers remain debuggable. - A temporary ClassScope is created during reparsing. After the class is reparsed, we use the information from the ScopeInfo to update the allocated indices of the variables in the ClassScope. Bug: v8:10704 Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#78299}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/0d9559b..9cfc745 Rolling v8/buildtools/linux64: git_revision:e0afadf7a743d5b14737bd454df45d5f1caf0d23..git_revision:fc295f3ac7ca4fe7acc6cb5fb052d22909ef3a8f Rolling v8/buildtools/third_party/libunwind/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libunwind/+log/74c6eec..c8c0ec9 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/02439f6..4983973 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/82f3512..0a233e1 Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/d61d4d8..4c5650f Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/fb06cff..336fcfd Rolling v8/tools/luci-go: git_revision:81212ba3aa0a1a724465bded12d12c16ed46da3a..git_revision:31175eb1a2712bb75d06a9bad5d4dd3f2a09cd1f Rolling v8/tools/luci-go: git_revision:81212ba3aa0a1a724465bded12d12c16ed46da3a..git_revision:31175eb1a2712bb75d06a9bad5d4dd3f2a09cd1f R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com Change-Id: Ife5892b51ffbc008a2f15bee4df6ebec29124b59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322892 Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#78298}
-
Milad Fa authored
Normal Wasm load/stores currently go through a byte reversing pipeline. Atomic load/stores however do not go through it and as a result do not produce the correct result on Big Endian platforms. This CL is adding this functionality to wasm-compiler by introducing a new macro `CASE_LOAD_STORE` which takes in an additional input `wasm::ValueType` needed by BuildChangeEndiannessLoad and Store. Change-Id: I138c6ea8baa07222cd86a791d70cb586e5594e97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3316032Reviewed-by:
-
Marja Hölttä authored
No-Try: true Change-Id: I9a1b12c0c1dd9863a78d7db33d9d43641336f60c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322834Reviewed-by:
-
Marja Hölttä authored
Bug: v8:11525 Change-Id: I7dee1987160d3811054a7be43280993630bca5be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320426Reviewed-by:
-
Patrick Thier authored
All uses of the build flag will be removed in a follow-up CL. Bug: v8:11112 Change-Id: Ifc3d9ed5d642646edeba51aa6d60924796d0f788 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322769 Auto-Submit: Patrick Thier <pthier@chromium.org> Reviewed-by:
-
Igor Sheludko authored
Ensure the bytecode array is available, before we put it to the PendingOptimizationTable. Bug: v8:12416 Change-Id: Ie4eb1a8a2ebdcdc0cfbfd7884eb081e156635a59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313108 Auto-Submit: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Clemens Backes authored
Make the block defining the counter names more organized, and mostly clang-formatted. This slightly changes the name of the CODE_TYPE and FIXED_ARRAY counters ('-' -> '_'), but none of them are used in chrome or in benchmarks, so this should be fine. R=mlippautz@chromium.org Bug: v8:12482 Change-Id: I4aa7d4e11a4f498f9adb092e3b98e1edf68401dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320454Reviewed-by: -
Thibaud Michaud authored
Treat all stack pointers as roots: - Maintain a global linked-list of StackMemories - Update StackFrameIterator to process inactive stacks - Visit roots in all inactive stacks (including root marking and root pointer updating). Drive-by: - Fix some issues uncovered by the test - Refactor the builtin constants R=mlippautz@chromium.org,ahaas@chromium.org Bug: v8:12191 Change-Id: I5b6381f9818166e2eabf80dd59135673dddb2afc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310932Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Nico Hartmann authored
to src/bigint/bitwise.cc. Bug: v8:11515 Change-Id: I20f8aebab138651247cedcd85460e40fbc255d98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310802Reviewed-by:
-
Leszek Swirski authored
Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo, which stores a couple of pointers and most importantly the Zone and AstValueFactory of the parse. This allows the Zone and AstValueFactory to be reused across multiple parses, rather than re-initialising per-Parse. With this, we can amend the LazyCompileDispatcher to initialise one LocalIsolate, Zone and AstValueFactory per background thread loop, rather than one per compile task, which allows us to reduce per-task costs and re-use the AstValueFactory's string table and previous String internalizations. Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106Reviewed-by:
-
Lu Yahan authored
Add func UseImmediate64(int64_t imm) into instruction-selector-impl Bug: v8:11976 Change-Id: I274ab59cc6d9a9cdc8b4081a7c418c56c3e8f5b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312453Reviewed-by:
ji qiu <qiuji@iscas.ac.cn> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Yahan Lu <yahan@iscas.ac.cn> Cr-Commit-Position: refs/heads/main@{#78288}
-
JianxiaoLuIntel authored
Change-Id: Ic79f5829ae47cb4217d424aa6582f4686751ff1a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3299279 Auto-Submit: Jianxiao Lu <jianxiao.lu@intel.com> Reviewed-by:
-
Maya Lekova authored
This reverts commit 58531652. Reason for revert: Breaks on gc stress variant - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/36600/blamelist Original change's description: > [wasm-gc] Allocate supertype arrays in old space > > We fix an inconsistency where supertype arrays for wasm-gc object maps > were not always allocated in old space. To do so we add an > AllocationType argument to a couple of factory helpers. > > Bug: v8:7748 > Change-Id: I8b16032b8504c17e0f730cfc86e30b172645b67b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320455 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78285} Bug: v8:7748 Change-Id: I74cf52c4f4da8948134f00bcf5415e9c65e509eb No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322752 Auto-Submit: Maya Lekova <mslekova@chromium.org> Owners-Override: Maya Lekova <mslekova@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@{#78286}
-
Manos Koukoutos authored
We fix an inconsistency where supertype arrays for wasm-gc object maps were not always allocated in old space. To do so we add an AllocationType argument to a couple of factory helpers. Bug: v8:7748 Change-Id: I8b16032b8504c17e0f730cfc86e30b172645b67b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320455Reviewed-by:
-
Marja Hölttä authored
Bug: v8:11525 Change-Id: Ida18808fd299f0f5754a2693b1e6dbc93b263d77 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320424Reviewed-by:
-
Benedikt Meurer authored
On the way to a cheaper and more scalable stack frame representation for the inspector (crbug/1258599), this removes the need to expose both what was called "function name" and what was called "function debug name" on a v8::StackFrame instance. The reason to having a distinction between that the V8 API exposes and what the inspector exposes as frame function name is that after the initial refactoring around v8::internal::StackFrameInfo, some wasm cctests would still dig into the implementation details and insist on seeing the "function name" rather than the "function debug name". This CL now addresses that detail in the wasm cctests and going forward unifies the function names used by the inspector and the V8 API (which is not only needed for internal consistency and reduced storage requirements in the future, but also because Blink for example uses v8 API and v8_inspector API interchangeably and assumes that they agree, even though at this point Blink luckily wasn't paying attention to the function name): - The so-called "detailed stack trace", which is produced for the inspector and exposed by the v8 API, always yields the "function debug name" (which for example in case of wasm will be a WAT compatible name), - while the so-called "simple stack trace", which is what is used to implement the CallSite API and underlies Error.stack continues to stick to the "function name" which in case of wasm is not WAT compatible). Bug: chromium:1258599 Change-Id: Ib15d038f3ec893703d0f7b03f6e7573a38e82b39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312274Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78283}
-
- 07 Dec, 2021 14 commits
-
-
Shu-yu Guo authored
With the TLA flag removed, EvaluateMaybeAsync is a misleading name. This CL renamed EvaluateMaybeAsync to Evaluate and consolidate it with the sync Evaluate method. Bug: v8:9344 Change-Id: I376ba9b9af0ac9e40a226cc8454f042ab7d9fb50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3309233Reviewed-by:
-
Corentin Pescheloche authored
This is a reland of 2d087f23 The changes are : * Fix redundant reinterpret_cast in test file for MSVC failure https://crbug.com/v8/12476 * Fix flaky test https://crbug.com/v8/12475 If a sample is captured during a GC, no embedder context is obtained defaulting to EMPTY. This is the expected behavior, made it in clear in implementation and in test. * Synchronized the embedder context filter behavior with existing native context filter. Original change's description: > Add APIs to surface VMState and new EmbedderState to CpuProfile samples. > > EmbedderState: > * An EmbedderState is defined as a value uint8_t and a v8::context used > for filtering. > * EmbedderStates are stack allocated by the embedder, construction and > destruction set/unset the state to the isolate thread local top. > * A v8::context is used to filter states that are added to a CpuProfile, > if the CpuProfile do not have a ContextFilter set or if contexts do not > match, state defaults to Empty. > > * v8:StateTag is already propagated all the way to a Sample, simply add > an API to surface it. > > VMState: > Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e > Bug: chromium:1263871 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072 > Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78250} Bug: chromium:1263871 Change-Id: Ief891b05da99c695e9fb70f94ed7ebdecc6c3b7b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320037 Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#78281}
-
Manos Koukoutos authored
We introduce a minimum length for the supertype array of gc maps. When the depth of the rtt is known to be smaller than that length, we can type check without bounds checking the supertype array of the object map. Bug: v8:7748, v8:11510 Change-Id: I88e67871040a8c4dd219e48a84527f7f3f3d0a96 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312487Reviewed-by:
-
Clemens Backes authored
Counter updates were already atomic, but reading the counter values was not. This lead to data races if one isolate called `quit` while other isolates were still running. This makes counters fully atomic, and reflects that by making the fields {std::atomic<int>}. R=mlippautz@chromium.org Bug: v8:12481, v8:12482 Change-Id: I6fc78ad6461b93c4b3e87bec052b0a67694539e3 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320428Reviewed-by: -
Clemens Backes authored
D8 shares counters across isolates, so even if they are only updated from the main thread, they need to be thread-safe. This CL removes the distinction between {StatsCounter} and {StatsCounterThreadSafe}, and just makes all {StatsCounter} use (cheap) atomic operations for counter updates. This will make previously thread-safe counters cheaper, because no Mutex is involved. It might make previously not-thread-safe counters slightly more expensive, but it's not expected to be a significant regression. R=mlippautz@chromium.org Bug: v8:12481, v8:12482 Change-Id: I47b8681c1cf26d142e1ccfafa0c192e3fdcb7d2a Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320427Reviewed-by: -
Patrick Thier authored
This reverts commit 863bc2b8. Reason for revert: https://crbug.com/1276923 Original change's description: > [turbofan] Improve StoreStoreElimination > > Previously, StoreStoreElimination handled allocations as > "can observe anything". This is pretty conservative and prohibits > elimination of repeated double stores to the same field. > With this CL allocations are changed to "observes initializing or > transitioning stores". > This way it is guaranteed that initializing stores to a freshly created > object or stores that are part of a map transition are not eliminated > before allocations (that can trigger GC), but allows elimination of > non-initializing, non-transitioning, unobservable stores in the > presence of allocations. > > Bug: v8:12200 > Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449 > Commit-Queue: Patrick Thier <pthier@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78230} Bug: chromium:1276923 Change-Id: I43dc3572ce1ef1fda42b7551ce8210d9f03e36ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318666 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by:
-
Michael Lippautz authored
Checks whether a Persistent is used from the creation thread on slow path allocations. In practice, these currently happen every 256 Persistent allocations. This is a best effort check that may help to flush out issues that are missed with DCHECK builds. Bug: chromium:1276570 Change-Id: Ia868ca436341b1b5ef427d5b3ec04926c1394e41 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318658 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/main@{#78276}
-
Jakob Kummerow authored
Allocating a temp register in a conditional branch confuses the LiftoffAssembler's state tracking, so this patch moves allocation of the register into the unconditional part of the control flow. Fixed: chromium:1275711 Change-Id: Ic83ba8c098c5edb33d035c1a93931d54cc1f1caa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320423 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Maya Lekova authored
This CL adds the following specific cases, to make sure they are correctly handled by the slow path: - the backing store of a TypedArray gets detached after optimisation - passing null instead of a TA doesn't lead to a deopt Bug: v8:11739, chromium:1052746 Change-Id: I7dfd3da9f535831901998ca6fad854af6e93e9f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320425Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/main@{#78274}
-
Dominik Inführ authored
Field used to be atomic for AssertActive() but now that this method uses another approach, we can make that field non-atomic again. Bug: v8:11708 Change-Id: I5254aa5e655844739082144fc75ba9f0c13d1ba0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3317424Reviewed-by:
-
Marja Hölttä authored
Bug: v8:11525 Change-Id: Iacdbc486de4aac3df6792f760ee216a5b6e62a27 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312276Reviewed-by:
-
Kim-Anh Tran authored
This removes the additional call to `didPause` solely for instrumentation breakpoints. They will be reported along with any other pause reasons, and if several apply, 'ambiguous' will be reported as a reason. Bug: chromium:1229541 Change-Id: I38557248dc2274c2ff2c396aa19073f4a5c5abd5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300134Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#78271}
-
Shu-yu Guo authored
Change-Id: I8b496a028601442b509f894ab29d70c53d67eef5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318732 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Concurrent marking got accidentally disabled because V8_ATOMIC_MARKING_STATE got removed. Bug: v8:12470, chromium:1277264, chromium:1277330, chromium:1277392 Bug: chromium:1277287, chromium:1277260, chromium:1277259 Bug: chromium:1277256, chromium:1277252, chromium:1277250 Bug: chromium:1277254, chromium:1277251 Change-Id: I21211e8f6d3a65714ba3204e87863b71af42d82d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318663 Auto-Submit: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
