- 07 Sep, 2020 2 commits
-
-
Camillo Bruni authored
This reverts commit 95aa697b. Reason for revert: breaks under tsan Original change's description: > [test][d8] Add d8.log.getAndStop helper > > The new helper function allows us to write tests for log parsing > without the need to first generating a log file. This makes it easier > to spot errors when the log format changes. > > - Add d8 global variable > - Add file_name accessor to Logger and Log classes > - Change OS::LogFileOpenMode to w+ / wb+ > - Use separate Log::WriteLogHeader method > - Remove unused logger_ instance variable from Log > > Bug: v8:10644 > Change-Id: Ifc7e35aa4e91b3f01f0847843263946e085944c3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387563 > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69715} TBR=mlippautz@chromium.org,cbruni@chromium.org,gsathya@chromium.org,verwaest@chromium.org Change-Id: Iad47d2f1e3391cae3c2f8c9e6c904c43925e1671 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10644 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396080Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#69717}
-
Camillo Bruni authored
The new helper function allows us to write tests for log parsing without the need to first generating a log file. This makes it easier to spot errors when the log format changes. - Add d8 global variable - Add file_name accessor to Logger and Log classes - Change OS::LogFileOpenMode to w+ / wb+ - Use separate Log::WriteLogHeader method - Remove unused logger_ instance variable from Log Bug: v8:10644 Change-Id: Ifc7e35aa4e91b3f01f0847843263946e085944c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387563 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#69715}
-
- 03 Sep, 2020 8 commits
-
-
Ng Zhi An authored
Functions with v128 in their signatures are always lowered to 4 word32. So if a return happens to be have an input that is a f32x4 operation, we get a register allocator error because it tries to fit a float into a general register. To fix that we need to do some checks when lowering kReturn, and for each input node, if we are returning a v128, and it is to be lowered into 4 f32 nodes, we bitcast the floats to ints. Bug: v8:10507 Change-Id: Iea2fdfc4057304ebf0898e6f7091124629c589f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391331 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#69705}
-
Dominik Inführ authored
Tests do not expect concurrent allocation and are simply skipped in that configuration. Bug: v8:10315 Change-Id: Ia371efa3c27e1f8b76fab47abcce2d7c218224bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390774Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69704}
-
evih authored
The generic wrapper can be used for Wasm functions with int32 parameters and 0 or 1 int32 return values. Added tests for cases when the return value can & cannot be converted to a Smi. Bug: v8:10701 Change-Id: I470954ed0aced0e4ec6e65a9f38caac19c576549 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390141 Commit-Queue: Eva Herencsárová <evih@google.com> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#69700}
-
Dominik Inführ authored
HeapWithPointerCompressionTest.HeapLayout sometimes raced with background threads. When iterating chunks, background threads might add chunks concurrently. Prevent this by enforcing safepoint during iteration. Bug: v8:10315 Change-Id: I2852ec3ea18905b669e60eadc660d9343ea35f48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390767 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69696}
-
Santiago Aboy Solanes authored
There is an int version that will be TNodified in a follow-up CL. Bug: v8:9708, v8:6949 Change-Id: I3a47cb352396dfe9dea426b6396216c06e0e3254 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387963 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#69695}
-
Ulan Degenbaev authored
This is a reland of 9eb090d2 The android-pie-arm64-dbg compiler error was fixed in: https://chromium-review.googlesource.com/c/v8/v8/+/2381450 Original change's description: > [heap] Add concurrent typed slot recording > > Since the typed slot set is not thread-safe, each concurrent marking > barrier collects typed slots locally and publishes them to the main > typed slot set in safepoints. > Bug: v8:10315 > > Change-Id: If1f5c5df786df88aac7bc27088afe91a4173c826 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370302 > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69576} Bug: v8:10315 Change-Id: Iae2882bad1cd0ffcae28c96318ba5fd7937f2215 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390763Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69694}
-
Ulan Degenbaev authored
Tests that use SimulateFullSpace and SealCurrentObjects do not work if there is a background thread allocating concurrently. Bug: v8:10315 Change-Id: I73a4c9db8eb32fdf3e07fcb8f5dda309de797709 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390765Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69693}
-
Ulan Degenbaev authored
ManualGCScope is used in tests that perform GC manually. Stressing concurrent allocation interferes with that and may trigger more GCs than the test expects. Bug: v8:10315 Change-Id: I6705f0b7cc555074b319a41d29810936b5a2a556 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2392242Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69691}
-
- 02 Sep, 2020 9 commits
-
-
Ng Zhi An authored
Due to the way SSE flags work, we need to enable all versions prior to SSE 4.1 as well. Bug: v8:10863 Change-Id: I50ddd3f486641e7bf22c651fc2c9a8a4ccbc2b46 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391325Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#69687}
-
Ng Zhi An authored
With https://crrev.com/c/2389982 we are now forcing the sse flag in this test, so we no longer need the flag check. Keep it around for the other archs. The nosse41 condition will be removed from the test runner in the next patch. Bug: v8:10863 Change-Id: I7eacb21803e6cc810384d3e4881d2a965dc1ad69 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391320Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#69684}
-
Etienne Pierre-doray authored
- JobHandle::IsCompleted() - JobDelegate::GetTaskId() - worker_count passed as argument to GetMaxConcurrency(). Jobs implementation must call the new GetMaxConcurrency(), but Jobs users aren't migrated yet. Bug: chromium:1114823 Change-Id: Ie09a8847d1cb884b1e388903370e49f33fa25a64 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2374308Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#69683}
-
HyeockJinKim authored
During spread operation, after VisitForAccumulatorValue, set the position of the current expression again Bug: chromium:929844 Change-Id: I6e9ca87587789f9cb21e939d4405414c8170b232 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379531 Commit-Queue: HyeockJin Kim <kherootz@gmail.com> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#69677}
-
Camillo Bruni authored
v8::String::IsExternal is confusing since it only checks for external two byte strings. The goal is to reintroduce String::IsExternal which checks for one and two byte external strings after removing the old, misleading api method. - Add String::IsExternalTwoByte - Deprecate String::IsExternal for now since it is misleading Bug: v8:10641 Change-Id: I8989de7576c823846e0536fc1898e769b6d68c87 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284495 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69674}
-
Martin Bidlingmaier authored
Previously we checked whether a thread's pc IsPcProcessed before pushing to the stack of (postponed) active_threads_. This commit moves the IsPcProcessed check and corresponding MarkPcProcessed call to when the thread is actually processed, i.e. when it is popped from the active_threads_ stack again. This fixes two issues: - Consider what used to happen in the following scenario: 1. An active thread t is postponed (e.g. because it is a fork) and pushed on active_threads_. IsPcProcessed(t.pc) is false, so t is not discarded and does actually end up on active_threads_. 2. Some other thread s is executed, and at some point s.pc == t.pc, i.e. t.pc is marked as processed. 3. t is popped from active_threads_ for processing. In 3 we don't want to continue execution of t: After all, its pc is already marked as processed. But because previously we only checked for IsPcProcessed in step 1 before pushing to active_threads_, we used to continue execution in 3. I don't think this is a correctness issue, but possibly a performance problem. In any case, this commit moves the IsPcProcessed check from 1 to 3 and so fixes this. - After flushing blocked_threads_, we push them to active_threads_ again. While doing so, we used to mark these thread's pcs as processed. This meant that sometimes a (fork of a) high priority thread was cancelled by the IsPcProcessed check even though its pc was only marked as processed by a thread with lower priority during flushing. We need it to be the other way round: The low priority thread should be cancelled after its pc is processed by a thread with higher priority. With this commit we don't MarkPcProcessed during flushing, it's postponed to when we're actually processing. This was a correctness issue, and there's a new corresponding test case. Bug: v8:10765 Change-Id: Ie12682cf3f8a04222d907edd8a3ad25baa69465a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388112 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#69668}
-
Andreas Haas authored
The test is slow and checks the limits of the WebAssembly implementation. Sanitizers are slower and therefore sometimes run into timeouts. Therefore we just disable the test for sanitizers. R=leszeks@chromium.org Change-Id: I4a0cb994dfc34097849f0dd8528dc158883fbc8a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2389980 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69667}
-
Michael Achenbach authored
The test is incompatible with --noenable-sse4-1, which is randomly added by numfuzz (and possibly other fuzzers). The "Flags" from the test files are always passed last and are often used to neuter incompatible flags. Bug: v8:10863 Change-Id: I8fd11b4d38586f25f5af63ab8ef83873dc250557 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2389982Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#69665}
-
Victor Gomes authored
This adds the argument count (as intptr) to the standard frame. StandardFrames are now in the same shape as OptimizedFrames. The argument count in the stack will be used to tear down the arguments when we remove the arguments adaptor frame. Change-Id: If9cc2946321bc1bb0abb776521e2d5b683ab0532 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312783 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69663}
-
- 01 Sep, 2020 10 commits
-
-
Arno Renevier authored
For TypedArray, a fast path is used when using the builtin iterator, and next method has not been overriden. If we use that fast path for JSArray too, the method will be about 200x times faster on a large array. This patch also fixes a bug when a typed array is modified during the mapper execution. In that case, the modification should not be taken into account. Bug: v8:10802 Change-Id: I74e2cbcd6a654def318585b4e08745037584669a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358749 Commit-Queue: Arnaud Renevier <arenevier@fb.com> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#69655}
-
Michael Lippautz authored
The handle was always created empty which resulted in a DCHECK crash in debug builds and in never-cancelled tasks in release builds. Bug: chromium:1056170 Change-Id: I798ce65c37738bbe9c60b44b692ff04536f6d830 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388101Reviewed-by:
Anton Bikineev <bikineev@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#69653}
-
Ng Zhi An authored
There were some +/- infs hidden in that list of NaNs (and those were repeated too). Add a NaN with top bit of payload unset. This will help catch cases where we did not canonicalize results properly. Bug: v8:10862 Change-Id: I05e3e0b2351430abf3eaa859a0d828f43b44cfb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2386483Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#69651}
-
Gus Caplan authored
Allows reflection of v8::Data types, such as being able to check if a value is a v8::Module. This is useful for libraries which wrap the V8 API, such as rusty_v8. Change-Id: I4841c5f7f60885b20e1504c8562e278844ff7ec3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2382719Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Gus Caplan <snek@chromium.org> Cr-Commit-Position: refs/heads/master@{#69649}
-
Andreas Haas authored
With a recent change, we require WebAssembly code to be tiered up to serialize it, see https://crrev.com/c/2349290. In that CL tests were adjusted to set the --wasm-tier-up flag when serialization was involved. However, the test adjusted in this CL was missing, because this test used the kExprRefNull instruction, which caused a bailout to TurboFan anyways. With recent changes, Liftoff can compile kExprRefNull now, and therefore causes problems. R=thibaudm@chromium.org Bug: v8:10852 Change-Id: I9b89f37c22f17cbf046110f3ee1c98bfea73e009 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387574Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#69648}
-
Peter Marshall authored
This adds a global counter for the various reasons we might fail to attribute a tick. The counters are cleared and printed when Profile::Print() is called, which we call in our tests, so flaky test output will now contain these stats along with the printed profile tree. Drive-by cleanup some print functions and make them const. Change-Id: Ia3a27405f5b5346adfdbb32afc7e414857969cc5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550406 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69647}
-
evih authored
The generic wrapper can be used for Wasm functions with int32 parameters and no return values. Changed the GC scanning for the generic wrapper. Added tests for cases when all the parameters of the Wasm function fit into registers and when some of the parameters are on the top of the stack. Change-Id: I511fd04d2a4a2bdc4a6f72d72e2867a03b256f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381459Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Eva Herencsárová <evih@google.com> Cr-Commit-Position: refs/heads/master@{#69645}
-
Andreas Haas authored
The fuzzer function is called multiple times with libfuzzer. Trap handlers, however, should only be initialized once. With this CL we add a flag to initialize trap handlers only once. R=clemensb@chromium.org Bug: chromium:1122590 Change-Id: Ib51a50cfe9dad5e3133de3085ad147f5a069b1bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384769 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69643}
-
Peter Marshall authored
This reverts commit dfb3f7da. Reason for revert: Breaks LSAN & ASAN flakily: https://bugs.chromium.org/p/v8/issues/detail?id=10861 Original change's description: > [cpu-profiler] Ensure sampled thread has Isolate lock under Windows > > While the sampler checked if the sampled thread had the Isolate locked > (if locks are being used) under Linux, the check was not done under > Windows (or Fuchsia) which meant that in a multi-threading application > under Windows, thread locking was not checked making it prone to seg > faults and the like as the profiler would be extracting info from a > heap in motion. The fix was to move the lock check into CpuSampler > and Ticker (--prof) so all OSes would do the correct check. > > The basic concept is that on all operating systems a CpuProfiler, and > so its corresponding CpuCampler, the profiler is tied to a thread. > This is not based on first principles or anything, it's simply the > way it works in V8, though it is a useful conceit as it makes > visualization and interpretation of profile data much easier. > > To collect a sample on a thread associated with a profiler the thread > must be stopped for obvious reasons -- walking the stack of a running > thread is a formula for disaster. The mechanism for stopping a thread > is OS-specific and is done in sample.cc. There are currently three > basic approaches, one for Linux/Unix variants, one for Windows and one > for Fuchsia. The approaches vary as to which thread actually collects > the sample -- under Linux the sample is actually collected on the > (interrupted) sampled thread whereas under Fuchsia/Windows it's on > a separate thread. > > However, in a multi-threaded environment (where Locker is used), it's > not sufficient for the sampled thread to be stopped. Because the stack > walk involves looking in the Isolate heap, no other thread can be > messing with the heap while the sample is collected. The only ways to > ensure this would be to either stop all threads whenever collecting a > sample, or to ensure that the thread being sampled holds the Isolate > lock so prevents other threads from messing with the heap. While there > might be something to be said for the "stop all threads" approach, the > current approach in V8 is to only stop the sampled thread so, if in a > multi-threaded environment, the profiler must check if the thread being > sampled holds the Isolate lock. > > Since this check must be done, independent of which thread the sample > is being collected on (since it varies from OS to OS), the approach is > to save the thread id of the thread to be profiled/sampled when the > CpuSampler is instantiated (on all OSes it is instantiated on the > sampled thread) and then check that thread id against the Isolate lock > holder thread id before collecting a sample. If it matches, we know > sample.cc has stop the sampled thread, one way or another, and we know > that no other thread can mess with the heap (since the stopped thread > holds the Isolate lock) so it's safe to walk the stack and collect data > from the heap so the sample can be taken. It it doesn't match, we can't > safely collect the sample so we don't. > > Bug: v8:10850 > Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108 > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69623} TBR=akodat@rocketsoftware.com,petermarshall@chromium.org,petermarshall@google.com Change-Id: Ib6b6dc4ce109d5aa4e504fa7c9769f5cd95ddd0c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10850 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387570Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#69638}
-
Santiago Aboy Solanes authored
Mostly a cleanup for x64. Also enable two tests for Arm and Arm64 since they do not make use of JSEntry frames. Bug: v8:10833 Change-Id: Id6adadf582bdca0076460842ffe4ec856ca99393 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381455 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#69634}
-
- 31 Aug, 2020 11 commits
-
-
Omer Katz authored
Heap growing estimates when to start incremental gc such that it will finish when we are expecting to finalize (i.e. when an atomic gc would be triggered). There is also a minimum ratio between limit for atomic gc and limit for incremental gc, to guarantee that incremental gc get's some time to run even with the application rarely allocates. This is a continuation of: https://chromium-review.googlesource.com/c/v8/v8/+/2377691 Bug: chromium:1056170 Change-Id: I8c87e98d60b6f8b5748558771a236f15385f7858 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381454Reviewed-by:
Anton Bikineev <bikineev@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/master@{#69630}
-
Milad Farazmand authored
Port 524fa743 Original Commit Message: This regression test does not work on MIPS without SIMD since the scalar lowering is not complete yet. Skip it for now. R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I0338593de3160dc0864c066e607b6030956e3efa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2386141Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#69629}
-
bcoe authored
Incrementing coverage counter was triggering EvalError for evaluateOnCallFrame when throwOnSideEffect is true. R=jgruber@chromium.org, sigurds@chromium.org, yangguo@chromium.org Bug: v8:10856 Change-Id: I0552e19a3a14ff61a9cb626494fb4a21979d535e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384011 Commit-Queue: Benjamin Coe <bencoe@google.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#69628}
-
Ng Zhi An authored
This regression test does not work on MIPS without SIMD since the scalar lowering is not complete yet. Skip it for now. Bug: v8:10831 Change-Id: Icc407488a96d4c965c1cf956f7a74abde078d421 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2385855Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#69626}
-
Arthur Eubanks authored
v8/test/cctest/interpreter/test-bytecode-generator.cc contains lots of string arrays with intentional concatenation. Bug: chromium:1114873 Change-Id: Ie9d35c3849b5b0a6d1d01b6ce21fb80a320d8736 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366829 Commit-Queue: Arthur Eubanks <aeubanks@google.com> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#69625}
-
Tianping Yang authored
By eager compile all functions in the startup snapshot, the startup snapshot can contain all function codes without warm-up. BUG=v8:4836 R=yangguo@chromium.org Change-Id: I07e86b6940c2fe75816df8ae429d110272216d0a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379535Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#69624}
-
Alex Kodat authored
While the sampler checked if the sampled thread had the Isolate locked (if locks are being used) under Linux, the check was not done under Windows (or Fuchsia) which meant that in a multi-threading application under Windows, thread locking was not checked making it prone to seg faults and the like as the profiler would be extracting info from a heap in motion. The fix was to move the lock check into CpuSampler and Ticker (--prof) so all OSes would do the correct check. The basic concept is that on all operating systems a CpuProfiler, and so its corresponding CpuCampler, the profiler is tied to a thread. This is not based on first principles or anything, it's simply the way it works in V8, though it is a useful conceit as it makes visualization and interpretation of profile data much easier. To collect a sample on a thread associated with a profiler the thread must be stopped for obvious reasons -- walking the stack of a running thread is a formula for disaster. The mechanism for stopping a thread is OS-specific and is done in sample.cc. There are currently three basic approaches, one for Linux/Unix variants, one for Windows and one for Fuchsia. The approaches vary as to which thread actually collects the sample -- under Linux the sample is actually collected on the (interrupted) sampled thread whereas under Fuchsia/Windows it's on a separate thread. However, in a multi-threaded environment (where Locker is used), it's not sufficient for the sampled thread to be stopped. Because the stack walk involves looking in the Isolate heap, no other thread can be messing with the heap while the sample is collected. The only ways to ensure this would be to either stop all threads whenever collecting a sample, or to ensure that the thread being sampled holds the Isolate lock so prevents other threads from messing with the heap. While there might be something to be said for the "stop all threads" approach, the current approach in V8 is to only stop the sampled thread so, if in a multi-threaded environment, the profiler must check if the thread being sampled holds the Isolate lock. Since this check must be done, independent of which thread the sample is being collected on (since it varies from OS to OS), the approach is to save the thread id of the thread to be profiled/sampled when the CpuSampler is instantiated (on all OSes it is instantiated on the sampled thread) and then check that thread id against the Isolate lock holder thread id before collecting a sample. If it matches, we know sample.cc has stop the sampled thread, one way or another, and we know that no other thread can mess with the heap (since the stopped thread holds the Isolate lock) so it's safe to walk the stack and collect data from the heap so the sample can be taken. It it doesn't match, we can't safely collect the sample so we don't. Bug: v8:10850 Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#69623}
-
Martin Bidlingmaier authored
This CL adds support for disjunctions and some quantification in EXPERIMENTAL regexp patterns. It is implemented using a new bytecode format and an NFA-based breadth-first interpreter. R=jgruber@chromium.org Bug: v8:10765 Change-Id: Idd49a3bbc9a9fcc2be80d822c9d84a638e53e777 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370634 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69621}
-
Jakob Gruber authored
The graph assembler calls MergeControlToEnd as part of Unreachable node creation; this causes issues when used inside the GraphReducer framework, since the reducer is not notified by gasm that the end node should be revisited. The (hacky) fix in this CL is to always mark the end node for revisitation after a gasm reduction has taken place. Bug: v8:8888,chromium:1123379 Change-Id: I350bb7144add04a0c3fd7f3d88c07fcfe1cd42e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384772 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69619}
-
Marja Hölttä authored
The goal is to have one graph per test case, and inside the graph, 4 different lines: - baseline - baseline noopt - super-ic - super-ic noopt Bug: v8:9237 Change-Id: I511b5555487a3d96698a3fb648abf76a13f76858 No-Try: True Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384770Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#69618}
-
Jakob Kummerow authored
A recent unrelated change caused these tests to get unlucky in GC stress mode. Their "assertOptimized" expectations rely on certain type feedback data not getting flushed at the wrong time. Bug: v8:10846 Change-Id: I86d0b0c049539e4a69aa764cc6ec92465ca12beb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381458Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#69617}
-