- 01 Sep, 2020 16 commits
-
-
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:
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}
-
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:
Anton Bikineev <bikineev@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#69644}
-
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}
-
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:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#69642}
-
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:
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@{#69631}
-
- 31 Aug, 2020 16 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:
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:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#69628}
-
Brendan Shanks authored
When running 64-bit Windows binaries on macOS using Wine, there is a conflict between macOS's use of GS to point to pthread thread-specific data, and Windows' use of GS to point to the TEB. Apple has reserved some TSD slots for use by Wine to store commonly-used TEB members (such as 0x30, the 'Self' pointer to the TEB). But, other direct GS accesses by Windows programs (such as to 'StackBase') will return macOS pthread data rather than the TEB member. This was causing a V8 unit test to crash on macOS under Wine. Using NtCurrentTeb() gets the 'Self' pointer first, then dereferences it to access the correct 'StackBase', fixing the crash. This turns GetStackStart() from one instruction into two. Chrome (http://crrev.com/c/2380425) and Crashpad also use NtCurrentTeb(). The 32-bit change isn't needed, but is just for consistency. Bug: chromium:1121842 Change-Id: I824f893aa451d8570142226be91840c964426f38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381941Reviewed-by:
-
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:
-
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:
-
Gus Caplan authored
PerformCheckCast<Data>() itself should not invoke Data::Cast(), since there is no such method and every publicly available value can be casted to it anyway. This is an issue in e.g. GetDataFromSnapshotOnce<Data>(). Change-Id: I5d9ee89657c31bc0ca1fb16e704df58911c85f6c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2383030 Commit-Queue: Gus Caplan <snek@chromium.org> Reviewed-by:
-
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:
-
Nico Hartmann authored
Bug: chromium:1120729 Change-Id: I27533a2426a63ec6b67d34d94f3cae554fc95d91 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379852 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
-
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:
-
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:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/0efd610..2dbf41f Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/6c48487..c73782c TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I6ca1f3428fd4c73446ecc2927a5493b42c39a73d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384549Reviewed-by:
-
Jake Hughes authored
With conservative stack scanning enabled, a snapshot of the call stack upon entry to GC will be 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. However, unlike with Handles, these on-stack pointers aren't guaranteed to point to the start of the object: the compiler may decide hide these pointers, and create interior pointers in C++ frames which the GC doesn't know about. The solution to this is to include an object start bitmap in the header of each page. Each bit in the bitmap represents a word in the page payload which is set when an object is allocated. This means that when the collector finds an arbitrary potential pointer into the page, it can walk backwards through the bitmap until it finds the relevant object's base pointer. To prevent the bitmap becoming stale after compaction, it is rebuilt during object sweeping. This is experimental, and currently only works with inline allocation disabled, and single generational collection. Bug: v8:10614 Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195 Commit-Queue: Anton Bikineev <bikineev@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
- 29 Aug, 2020 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/f9767b5..0efd610 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ffb1227..6c48487 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/b64a74c..89d15db TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Ic0508bbd94bd2fa1e9d58002694bc9bb939bcd7e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2382433Reviewed-by:
-
- 28 Aug, 2020 7 commits
-
-
Ng Zhi An authored
For SIMD instructions that use aligned moves (like movaps or movapd), we don't have correct memory alignment for SIMD moves yet. Switch to to movupd. Bug: v8:9198 Bug: v8:10831 Change-Id: Ic60fba5d08dda9676f6091ce505ac7be54957d00 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380240 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Ng Zhi An authored
This allows tests to be skipped on nosse41 builds. For SIMD, nosse41 means that we need to scalar lower all SIMD instructions, which is not fully implemented yet. Bug: v8:10831 Change-Id: I27dd2840b376da672237fed764cbd2491c244627 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380710Reviewed-by:
Liviu Rau <liviurau@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#69612}
-
Clemens Backes authored
Even though we provide a --wasm-max-code-space flag (defaulting to {kMaxWasmCodeMB}, we still had checks in place that the actual committed code space is not bigger than that constant. This CL fixes that by always comparing against the value of the flag. This will allow us to specify a code space limit which is larger than the default. This is useful when debugging larger Wasm apps which exceed the limit, but are not meant to be shipped that way. Drive-by: Remove a dead use of the {kMaxWasmCodeMemory} constant. R=ecmziegler@chromium.org Bug: chromium:1117033, chromium:1114093, chromium:1107649, chromium:1111266 Change-Id: I2684446230a8a6f0a27ad963dd6f36e5764b25e0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376810Reviewed-by:Emanuel Ziegler <ecmziegler@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69611}
-
Zeynep Cankara authored
This CL adds a source code panel to display source code positions of Map/IC log events. * Clicking file positions on the Ic Panel emits FocusEvent with SourcePositionLogEvent as entry to highlight code related with the selected icLogEvent. * Clicking map details on the Map Panel emits FocusEvent with SourcePositionLogEvent as entry to highlight code related with the selected mapLogEvent. Bug: v8:10644 Change-Id: Icaf3e9e3f7fae485c50ad685f9ec5dc8ac28b3dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358734 Commit-Queue: Zeynep Cankara <zcankara@google.com> Reviewed-by:
-
Clemens Backes authored
Those globals must have type float instead of int to preserve the sign bit. R=ahaas@chromium.org Bug: chromium:1069173 Change-Id: I9769f47f087aaba94a6172118be44f70adeded0c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379861Reviewed-by:
-
Clemens Backes authored
These trace events can be used for triaging profiling issues. We already have one event if code logging is triggered via an interrupt. The new events will be emitted if called via the foreground task, or just directly (e.g. after deserialization). R=ecmziegler@chromium.org Change-Id: I67ad9568f38d9a6eb98abf53ce5542ed56170c60 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376811Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/2841b25..f9767b5 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f9ede33..77fb6d1 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/7d98e22..ffb1227 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Ica76a0a38bda603347cb3e97ebf2884507415d8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381179Reviewed-by:
-
