- 02 Sep, 2020 8 commits
-
-
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}
-
Ulan Degenbaev authored
Garbage collection requests from background threads are ignored if the heap is tearing down. This fixes CanExpandOldGenerationBackground to check for that case. Bug: v8:10315 Change-Id: I79b6a4446bf3c9037dbca54849c87f022be76b49 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387964 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
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:
-
Cong Zuo authored
PrintRegisters() should print output to `os` argument for unification, and in case of the function would be used by other files. Bug: v8:10821 Change-Id: Ia825c4deaf89ec454b7c293367cfa362acd4cccc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2371543Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#69664}
-
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:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69663}
-
Leszek Swirski authored
https://crrev.com/c/2369172 had a few remaining comments that accidentally weren't addressed in the final submitted patch. Tbr: jgruber@chromium.org Change-Id: If0cff18f5078f17a6f70d27c71090dcc64f23ddd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388114Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69662}
-
Michael Lippautz authored
Change-Id: I4e2a0ddbeba68a4cc136bb6d56383b0a7e4f1dff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388107 Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#69661}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/482dd77..6d55754 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/1eb42f5..156bfc1 Rolling v8/third_party/requests: https://chromium.googlesource.com/external/github.com/kennethreitz/requests/+log/refs/ta..bfb93d4 Rolling v8/third_party/zlib: https://chromium.googlesource.com/chromium/src/third_party/zlib/+log/d53accf..59187e1 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/fcef86e..03bacc3 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Iceea7cbadbbe4e8a480517051425d1a44d76066d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388173Reviewed-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@{#69660}
-
- 01 Sep, 2020 29 commits
-
-
Ng Zhi An authored
We were using vqsub incorrectly (which saturates), we need vsub (wraparound). Found this issue while running spec test simd_i64x2_arith.js. Bug: v8:10835 Change-Id: Ic9d45d69e64fa5ff9ddad5de4690f3dd32d1384e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2389100Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#69659}
-
Seth Brenith authored
This reverts commit 7f054679. Reason for revert: regressions on Emscripten/Fannkuch and JetStream/richards Original change's description: > [regalloc] Run SpillPlacer on any value defined in a loop > > I previously wrote a comment that said "We haven't seen any indication > of performance improvements from seeking optimal spilling positions > except on loop-top phi values". That statement is no longer true, now > that I've looked a little harder. In the latest version of the Mono > interpreter, we can improve performance by 2.5% by enabling SpillPlacer > for any value defined within a loop. > > Bug: v8:10606 > Change-Id: I25e06458c87ad4ffcefe52be3042032e05a47b35 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381557 > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#69646} TBR=rmcilroy@chromium.org,seth.brenith@microsoft.com,thibaudm@chromium.org Change-Id: Ic3e74485f42bafedfe1890c0be32a29c3455afe5 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10606, chromium:1124028 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388745Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#69658}
-
Ng Zhi An authored
Swizzle codegen was incorrect when mask == dst, which can happen since we did not pin dst. We can simplify this by using scratch register for mask. This bug was encountered while trying to run the spec test simd-lane.js. Bug: v8:10835 Change-Id: Ie9c8f383bb6f336f9b74955fb7a9aee0e6774bf2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388743Reviewed-by:
-
Bill Budge authored
- Restores the old inline code sequence, since the branching version doesn't set the NaN high bit. Bug: v8:10862 Change-Id: Iad8ee47b678cc1c6c04222dd83b2fa588ea9136c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387557Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#69656}
-
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:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#69655}
-
Michael Achenbach authored
NOTRY=true TBR=leszeks@chromium.org Change-Id: I5abb432e42168484aabf04600e8e2cf6e3511630 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388105Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#69654}
-
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
Fuzzers use a slight variant of the sse4_1 flag, see https://source.chromium.org/chromium/chromium/src/+/master:v8/tools/testrunner/testproc/fuzzer.py;l=26;drc=9491d5eaa4e764721b5269e75af68f181bef09cf. Bug: v8:10863 Change-Id: Ifc467644f00a4f10776794c12a227f13774f48ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387555Reviewed-by:
-
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:
-
Z Nguyen-Huu authored
Marked GetStackFrameId V8_DEPRECATED Bug: v8:10566 Change-Id: I2e225eae7d0375cff7b9f79e4c38802265940219 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352475 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#69650}
-
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}
-
Seth Brenith authored
I previously wrote a comment that said "We haven't seen any indication of performance improvements from seeking optimal spilling positions except on loop-top phi values". That statement is no longer true, now that I've looked a little harder. In the latest version of the Mono interpreter, we can improve performance by 2.5% by enabling SpillPlacer for any value defined within a loop. Bug: v8:10606 Change-Id: I25e06458c87ad4ffcefe52be3042032e05a47b35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381557Reviewed-by:
-
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:
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}
-
Jake Hughes authored
When enabled with the v8_enable_conservative_stack_scanning flag, a snapshot of the call stack upon entry to GC is used to determine part of the root-set. When the collector walks the stack, it looks at each value and determines whether it could be a potential on-heap object pointer. This is very experimental. For conservative stack scanning to work, direct handles must be implemented. Bug: v8:10614 Change-Id: Id4209cfbe76ef02239c903fabcb7f677b32fc977 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375201 Commit-Queue: Anton Bikineev <bikineev@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
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:
-
Leszek Swirski authored
Unify the encoding/decoding of values into a ranged bytecode with a single templated class that takes the bytecode, minimum, and maximum, and provides Encode and Decode methods. This class also handles range checks on both the input and output, which (along with a few other byte cases) allows us to get rid of the PutSection method. Change-Id: Icb2cd409607ce7b650226eb8dca80c0e363a8acc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2369172 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Leszek Swirski authored
This fixes the Android Arm perf build after https://crrev.com/c/2365216 TBR=machenbach@chromium.org Fix: v8:10867 Change-Id: Ic67c0d8b6334179356a6662a352039e445f92389 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387572 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#69641}
-
Junliang Yan authored
Change-Id: Ica6b886ca0b16ab6eb86f3a90c598a0801230648 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2385918Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69640}
-
Clemens Backes authored
If multiple recompilations are triggered at the same time, we cannot contribute to compilation, because this would bump the number of workers above the maximum expected concurrency. This is a quick fix, a better (but more involved) fix would be to make the number of queues grow dynamically. R=thibaudm@chromium.org Bug: chromium:1123471 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Change-Id: I30e4b2a057098ad7267ae942e5845b0cefe60e0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387561Reviewed-by:
-
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}
-
Martin Bidlingmaier authored
Bug: v8:10765 Change-Id: I49e425d861d900ab66b6f7801cddec8a7175ac03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2385462 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by:
-
Leszek Swirski authored
Change the serialization protocol to ensure that maps are serialized before objects using them. This ensures that as soon as we allocate space for an object, we can immediately write the object's map into that allocation. In the future, this will allow us to make deserialized object visible to the GC. Specifically, this forces map serialization to happen after emitting a kNewObject for an object, but before allocating the space for it. We have to serialize the map after kNewObject because otherwise the map itself would be written into the "current" slot, into which the object is supposed to be deserialized. Objects whose maps are currently being deserialized are considered "pending" -- started, but not yet allocated. The map might point to a pending object (e.g. if an object's constructor points to the object). This is solved by introducing a new concept of forward references, where the field referring to the pending object is serialized as a "pending forward reference" which is "resolved" once the object is allocated. It might also point to itself, in the case of the meta map -- this is simply solved by introducing a new bytecode for the meta map; this cannot be a pending forward reference because the meta map is not yet allocated, so its map slot cannot be registered as pending. Finally, we may need to go to a new chunk after serializing the map; so after the map serialization, we peek to see if there's a next chunk bytecode before the object allocation. Bug: v8:10815 Change-Id: Ifa8f25bdaf3b15b5d990a1d2e7be677c2fa80013 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362953 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Rewrite the deserializer case macros to look, to formatters, more like a single case value, and clean up some of the repetition to be more explicit, e.g. replace SIXTEEN_CASES(kFoo) impl() with case CASE_REPEAT(kFoo, 16): impl() This should help with auto-formatting issues when modifying the big deserializer switch statement. As a drive-by, also clean up the per-space case macros to use a function rather than a macro for specifying the bytecode, and add helpers for encoding fixed raw data size in the bytecode (similar to the existing helper for fixed repeat counts). Change-Id: I885ba79afef03b95ad64cd78bdfba5dffc82be1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2367853 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: -
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:
-
Clemens Backes authored
{std::atomic} is being used in the header without including the <atomic> header. It was reported on the v8-users list that this causes compile errors on Windows. R=ulan@chromium.org Change-Id: I1de19c301ce47787628416bf0e744d0dd7507fa3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387562Reviewed-by: -
Frank Tang authored
This is a reland of c6d3516f Original change's description: > [Intl] Ship Intl.Segmenter > > Spec: https://tc39.es/proposal-intl-segmenter/ > ECMA402 site: https://github.com/tc39/proposal-intl-segmenter > I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/MJ1OpvkcA8s/m/mYNxpwqSCAAJ > I2I: https://groups.google.com/a/chromium.org/g/blink-dev/c/muRQBwyzzPw/m/rB_2I9t0CQAJ > Design Doc: https://docs.google.com/document/d/1xugLpLmgRFnNXK8ztariTAbD2IXueDw1T3VNuuZCz8k/edit > CPS: https://www.chromestatus.com/feature/6099397733515264 > Test262 Tests: https://github.com/tc39/test262/tree/main/test/intl402/Segmenter > v8 tests: https://source.chromium.org/chromium/chromium/src/+/master:v8/test/intl/segmenter/?q=test%2Fintl%2Fsegmenter&ss=chromium > > Approved by API Owners: yoav@yoav.ws / chrishtr@chromium.org / bratell.d@gmail.com > > Bug: v8:6891 > Change-Id: I64775ed63557a9e1af77560abd42349742bc4c03 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376967 > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69593} Bug: v8:6891 Change-Id: I0908c859ce4c7875860f5839a2548b55daea3c89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380440 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/2dbf41f..482dd77 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/77fb6d1..1eb42f5 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/c73782c..ed15af5 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/89d15db..fcef86e TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Id3cf39f4f058d8cd46c93c6ccc5edf6c345f7d0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2386623Reviewed-by:
-
- 31 Aug, 2020 3 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:
-
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:
-
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:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#69628}
-
