- 09 Feb, 2021 1 commit
-
-
Brice Dobry authored
This very large changeset adds support for RISC-V. Bug: v8:10991 Change-Id: Ic997c94cc12bba6881bc208e66526f423dd0679c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571344 Commit-Queue: Brice Dobry <brice.dobry@futurewei.com> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#72598}
-
- 03 Dec, 2020 1 commit
-
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: I108a847e12df2438cc73e4f7a31ba4148f07cdc0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569562 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#71593}
-
- 25 Nov, 2020 1 commit
-
-
Santiago Aboy Solanes authored
This allows us to assert at compile time that a class instance is assigned, which is particularly useful for Guard classes. Change-Id: Id16b2bb70d29573566e821c908c1169d49ec57af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2552415 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#71397}
-
- 28 Oct, 2020 1 commit
-
-
Peter Marshall authored
This has no effect on our normal V8 builds as we don't set an alternate stack. Embedders like Go have to use alt stacks so this makes them work with V8 if they have set up an alt stack themselves. Change-Id: Icf3f4b39c026948875f5b2762ea6ffabaab03e8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505718Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#70855}
-
- 20 Oct, 2020 1 commit
-
-
Edward Lesmes authored
Generate DIR_METADATA files and remove metadata from OWNERS files for v8. R=jkummerow@chromium.org, ochang@chromium.org, yangguo@chromium.org Bug: chromium:1113033 Change-Id: I82cbb62e438d82dbbc408e87120af39fa9da0afa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476680Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Edward Lesmes <ehmaldonado@chromium.org> Auto-Submit: Edward Lesmes <ehmaldonado@chromium.org> Cr-Commit-Position: refs/heads/master@{#70669}
-
- 16 Sep, 2020 1 commit
-
-
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 using isolate->js_entry_sp to determine the stack to walk but isolate->js_entry_sp is the stack pointer for the thread that currently has the Isolate lock so, if the sampled thread does not have the lock, the sampler woud be iterating over the wrong stack, one that might actually be actively changing on another thread. 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: Iba6cabcd3e11a19c261c004103e37e806934dc6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411343Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#69952}
-
- 01 Sep, 2020 2 commits
-
-
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}
-
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}
-
- 31 Aug, 2020 1 commit
-
-
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}
-
- 29 Jun, 2020 1 commit
-
-
Nico Weber authored
Bug: chromium:1098899 Change-Id: I3ff79c00063f7da36b141a3a7b0d2daa71c9801a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270705 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Auto-Submit: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68568}
-
- 09 Jun, 2020 1 commit
-
-
Ng Zhi An authored
See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-bool-literals.html. Bug: v8:10488 Change-Id: I0808eee42c3339d9de653125b0d853b8ae5e5540 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2233856Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#68243}
-
- 21 Feb, 2020 1 commit
-
-
Wouter Vermeiren authored
After support for ARCH_PPC was dropped, it became a subset of ARCH_PPC64. If you compile for ppc64, then you set the ARCH_PPC64 define which also sets the ARCH_PPC define. To be able to again support ppc (32 bit) those defines should be split up again. This commit only splits up the defines but does not introduce a working ARCH_PPC variant. Bug: v8:10102 Change-Id: I64e0749f8e5a7dc078ee7890d92e57b82706a849 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989826 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66390}
-
- 28 Nov, 2019 1 commit
-
-
David Carlier authored
Those fields are incorrect in FreeBSD. Upstreaming local FreeBSD patches. Change-Id: I28cf6dbec1d5e4d26e62dd9a0d78d039c3e36cdb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1906374Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65226}
-
- 13 Sep, 2019 1 commit
-
-
Clemens Hammacher authored
After https://crrev.com/c/1800575 and https://crrev.com/c/1803343, which tried to fix this on occuring compile errors, this CL systematically adds the <memory> include to each header that uses {std::unique_ptr}. R=sigurds@chromium.org TBR=mlippautz@chromium.org,alph@chromium.org,rmcilroy@chromium.org,verwaest@chromium.org Bug: v8:9396 Change-Id: If7f9c3140842f9543135dddd7344c0f357999da0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803349Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63767}
-
- 10 Sep, 2019 1 commit
-
-
Clemens Hammacher authored
Since we switched to C++14 now, we can use {std::make_unique} instead of our own {base::make_unique} from {template-utils.h}. R=mstarzinger@chromium.org, yangguo@chromium.org Bug: v8:9687 No-Try: true Change-Id: I660eb30038bbb079cee93c7861cd87ccd134f01b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789300 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63642}
-
- 30 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: Id6860e7b0f932990ac3cda39e369b0809e4f6a2b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632072Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61928}
-
- 28 May, 2019 1 commit
-
-
Clemens Hammacher authored
Just use standard C++ syntax to define structs and enums instead. R=ahaas@chromium.org Bug: v8:9183 Change-Id: Ibae1643bd1dc74267cdd14ec45a36fc65bf0ab4b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631410Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61889}
-
- 27 May, 2019 1 commit
-
-
Clemens Hammacher authored
This replaces all typedefs that define types and not functions by the equivalent "using" declaration. This was done mostly automatically using this command: ag -l '\btypedef\b' src test | xargs -L1 \ perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg' Patchset 2 then adds some manual changes for typedefs for pointer types, where the regular expression did not match. R=mstarzinger@chromium.org TBR=yangguo@chromium.org, jarin@chromium.org Bug: v8:9183 Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61849}
-
- 17 May, 2019 1 commit
-
-
Milad Farazmand authored
Port 8e7945a6 Original Commit Message: Port 381a7f9e Original Commit Message: On Arm/64 the last return address is stored in a link register instead of being pushed to the top-of-stack like on x64/ia32. Extend the support in the tick sampler to check for samples in a frameless bytecode handler with support for checking the link register if it exists instead of top-of-stack. In addition, make the x64/ia32 check more robust by ensuring we only apply the change if the pc is a bytecode handler and the top frame isn't a bytecode handler (stub) frame. R=miladfar@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:9162 LOG=N Change-Id: I52c40f8d4ba1bb10049410417d1e60f95315489d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1614791Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Reviewed-by: Joran Siu <joransiu@ca.ibm.com> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#61605}
-
- 02 May, 2019 1 commit
-
-
Milad Farazmand authored
Port 381a7f9e Original Commit Message: On Arm/64 the last return address is stored in a link register instead of being pushed to the top-of-stack like on x64/ia32. Extend the support in the tick sampler to check for samples in a frameless bytecode handler with support for checking the link register if it exists instead of top-of-stack. In addition, make the x64/ia32 check more robust by ensuring we only apply the change if the pc is a bytecode handler and the top frame isn't a bytecode handler (stub) frame. R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:9162 LOG=N Change-Id: I893b45af40a48415fbbc2c9f5e9e5cd72ed8d9e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588888Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#61173}
-
- 24 Apr, 2019 1 commit
-
-
Ross McIlroy authored
On Arm/64 the last return address is stored in a link register instead of being pushed to the top-of-stack like on x64/ia32. Extend the support in the tick sampler to check for samples in a frameless bytecode handler with support for checking the link register if it exists instead of top-of-stack. In addition, make the x64/ia32 check more robust by ensuring we only apply the change if the pc is a bytecode handler and the top frame isn't a bytecode handler (stub) frame. BUG=v8:9162 Change-Id: I89d2e80ea8a0b84ff6a265d0e0e73f9fdd1daca8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578464Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#60976}
-
- 17 Apr, 2019 2 commits
-
-
Jakob Gruber authored
This adds support for iOS builds in libsampler. Both iOS simulator builds (target architecture x64) and iOS device builds (arm64) are supported. Note that this is mostly untested since we neither have iOS bots nor an iOS test runner. This CL was thus only tested by compiling V8 for both iOS simulator & device targets. Bug: v8:9140 Change-Id: Ib618bf793771f4be84d1979a968d2b3ef9f6ff86 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1569436Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#60898}
-
Jakob Gruber authored
OS X has been a UNIX 03 registered product since version 10.5, released in October 2007. Bug: v8:8834 Change-Id: I64ca5512a9999b6eb7b4003a6758081a06eb6529 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1569437 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#60891}
-
- 27 Mar, 2019 1 commit
-
-
Sigurd Schneider authored
Bug: v8:9020 Change-Id: I851e9a18eab0812e009d323cd98814bebc83f003 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541047 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#60487}
-
- 14 Feb, 2019 1 commit
-
-
Alexei Filippov authored
Change-Id: I4f7c80f89ad4d023f96a9113ebb6628df44fb61c Reviewed-on: https://chromium-review.googlesource.com/c/1469325Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#59607}
-
- 13 Feb, 2019 1 commit
-
-
Andrew Comminos authored
Sets an atomic field on each sampler when it requests a sample, to be checked when the SIGPROF handler is executed. A counter is not used since signals may be coalesced. Prior to this change, all samplers attached to an isolate received samples when other samplers sent SIGPROF to the VM thread. This change alters the behaviour of different CpuProfiler instances on the same isolate to be in line with the Windows / Fuchsia behaviour. Bug: v8:8835 Change-Id: I0caaa845b596efc9d8b1cd7716c067d9a6359c57 Reviewed-on: https://chromium-review.googlesource.com/c/1468941 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#59545}
-
- 21 Jan, 2019 4 commits
-
-
Peter Marshall authored
Simplify the internal state of Sampler a bit. There are basically two users of Sampler - the CpuSampler used by the CpuProfiler and the Ticker used by log.cc. Ticker calls Start/Stop to manage the Sampler lifetime, but CpuProfiler does not. This leads to much confusion and overlap of functionality. Fix that here by removing the distinction between active, registered and isProfiling states. These are now all the same thing and are represented by IsActive(). The state is set to active when Start is called, and set inactive when Stop is called. Both users of Sampler now call Start and Stop at appropriate times. The concept of profiling depth was not used - each Sampler would only ever have a sampling depth of 1. We still need to call SignalHandler::IncreaseSamplerCount(), so we do that in Start and the corresponding DecreaseSamplerCount() in Stop. Change-Id: I16a9435d26169a7dd00b1c7876e66af45f12e4b0 Reviewed-on: https://chromium-review.googlesource.com/c/1424337 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58955}
-
Peter Marshall authored
There's no reason to use our self-baked atomics anymore. Also - Changes two boolean values to use a boolean instead of an int - Uses a unique ptr for data_ - Removes has_processing_thread_ which is not used - Moves most initialization inline into the class - Removes SetUp/TearDown which weren't needed Change-Id: I8f50133636961502d56351abd2fb17196603a01a Reviewed-on: https://chromium-review.googlesource.com/c/1422918 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58950}
-
Peter Marshall authored
Moved class definitions into header Change-Id: I2d3e5ec6f8f5068284cdbaa6900797950fc7e01a Reviewed-on: https://chromium-review.googlesource.com/c/1422739 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58946}
-
Peter Marshall authored
There is no reason to use the custom map here anymore. This lets us get rid of the custom hash and a lot of casts. We can also store the SamplerList by value in the map rather than a pointer, then we don't have to manage the lifetime explicitly. Also move the SamplerList typedef inside of SamplerManager because it's an internal detail. Remove the include for <map> because we aren't using this anywhere anyway. Change-Id: I787a1b6c3ffc331ec3f36e66d5e07bd115c4cbb4 Reviewed-on: https://chromium-review.googlesource.com/c/1419317Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#58945}
-
- 18 Jan, 2019 2 commits
-
-
Peter Marshall authored
Use more idiomatic c++ and add slightly better comments. Change-Id: Id6397a25851915eb10a0370d23dc41ca7fce3c2e Reviewed-on: https://chromium-review.googlesource.com/c/1418194Reviewed-by: Alexei Filippov <alph@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#58937}
-
Peter Marshall authored
This changes the compare/exchange operation to the 'strong' one which avoids potential spurious failures. These failures would be hidden by the loop in AtomicGuard - except that we only ever call compare_exchange_weak once when is_blocking is false. See the linked bug for more info. Bug: v8:8649 Change-Id: I94ebe04e86f4676d2b7404d833157f61d5df8a59 Reviewed-on: https://chromium-review.googlesource.com/c/1418190Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#58909}
-
- 16 Jan, 2019 1 commit
-
-
Peter Marshall authored
This doesn't need to be static as the whole SamplerManager class has only one static instance anyway, via instance(). This might also fix the weird lock behavior we are seeing on Nexus 5x where the atomic_bool lock seems to never be released. Bug: v8:8649 Change-Id: If44b6361c9e2a124265ca5b15b997538475a2ec9 Reviewed-on: https://chromium-review.googlesource.com/c/1414854Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#58847}
-
- 15 Jan, 2019 2 commits
-
-
Maya Lekova authored
This reverts commit 48feba60. Reason for revert: Some TSAN failures reoccurred - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20TSAN/24456 Original change's description: > Reland "[cpu-profiler] Add more logging to find flaky failure" > > This is a reland of 138bcfc3 > > Fixed all the data races and ran TSAN locally to confirm. > > Original change's description: > > [cpu-profiler] Add more logging to find flaky failure > > > > There is a flaky 5x failure in the tree which I can't reproduce locally. > > This extra logging will help flush out what the problem is. > > > > Bug: v8:8649 > > > > Change-Id: If36d2ce0f4feb398d7d746d69b417bb55a714422 > > Reviewed-on: https://chromium-review.googlesource.com/c/1402787 > > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#58796} > > Bug: v8:8649 > Change-Id: I53e293ef85a54d4b2b39aa3b980832031201aa0c > Reviewed-on: https://chromium-review.googlesource.com/c/1411633 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58833} TBR=jgruber@chromium.org,petermarshall@chromium.org Change-Id: Icd779b0bd0faf1db76a17736b70617e6b1d6584f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8649 Reviewed-on: https://chromium-review.googlesource.com/c/1412458Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#58834}
-
Peter Marshall authored
This is a reland of 138bcfc3 Fixed all the data races and ran TSAN locally to confirm. Original change's description: > [cpu-profiler] Add more logging to find flaky failure > > There is a flaky 5x failure in the tree which I can't reproduce locally. > This extra logging will help flush out what the problem is. > > Bug: v8:8649 > > Change-Id: If36d2ce0f4feb398d7d746d69b417bb55a714422 > Reviewed-on: https://chromium-review.googlesource.com/c/1402787 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58796} Bug: v8:8649 Change-Id: I53e293ef85a54d4b2b39aa3b980832031201aa0c Reviewed-on: https://chromium-review.googlesource.com/c/1411633 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58833}
-
- 14 Jan, 2019 2 commits
-
-
Michael Achenbach authored
This reverts commit 138bcfc3. Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20TSAN/24434 Original change's description: > [cpu-profiler] Add more logging to find flaky failure > > There is a flaky 5x failure in the tree which I can't reproduce locally. > This extra logging will help flush out what the problem is. > > Bug: v8:8649 > > Change-Id: If36d2ce0f4feb398d7d746d69b417bb55a714422 > Reviewed-on: https://chromium-review.googlesource.com/c/1402787 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58796} TBR=cbruni@chromium.org,petermarshall@chromium.org Change-Id: Iea4a950ddbbbbc753cffc605f0c0da049cdad03d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8649 Reviewed-on: https://chromium-review.googlesource.com/c/1409433Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#58800}
-
Peter Marshall authored
There is a flaky 5x failure in the tree which I can't reproduce locally. This extra logging will help flush out what the problem is. Bug: v8:8649 Change-Id: If36d2ce0f4feb398d7d746d69b417bb55a714422 Reviewed-on: https://chromium-review.googlesource.com/c/1402787 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#58796}
-
- 02 Jan, 2019 1 commit
-
-
Clemens Hammacher authored
Introduce a LeakyObject template and use that to implement static lazily initialized objects that never get destructed. This was done in a hand-crafted and complex way before via LazyInstance and LazyStaticInstance. R=tebbi@chromium.org Bug: v8:8600, v8:8562 Change-Id: Id160996753b2cb1baf0f4b2cec9e1727f1d01512 Reviewed-on: https://chromium-review.googlesource.com/c/1388539 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58494}
-
- 25 Oct, 2018 1 commit
-
-
Peter Marshall authored
This is a reland of c92a1dda Original change's description: > [cpu-profiler] Fix a bug which caused a pure virtual function call > > We need to remove each Sampler from the SamplerManager before we call > the Sampler destructor. This is because the signal handler can interrupt > the destructor, and call DoSampler(), which calls sampler->SampleStack() > on the sampler being destructed, causing general unhappiness and > "Pure virtual function called!" crashes. > > Bug: v8:8346, v8:5193 > Change-Id: Iaa595a196eab33fb1af31584e9a68fd1ce0a18f6 > Reviewed-on: https://chromium-review.googlesource.com/c/1293949 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Alexei Filippov <alph@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56882} TBR=yangguo@chromium.org Bug: v8:8346, v8:5193 Change-Id: I9878f65c868ff1aed6f3a587cba688c4241bad8c Reviewed-on: https://chromium-review.googlesource.com/c/1298893Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#56976}
-
- 24 Oct, 2018 1 commit
-
-
Tom Tan authored
This is a reland of fcbb023b Original change's description: > Add Windows ARM64 ABI support to V8 > > This change added Windows ARM64 ABI support, major things are: > 1. Excluding x18 register from any usage because it is reserved as > platform register. Preserve alignment after the change. > 2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is > still LLP64. > 3. Stack guard page probe for large allocation on stack. > > Reference: > Windows ARM64 ABI: > https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017 > > Bug: chromium:893460 > Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e > Reviewed-on: https://chromium-review.googlesource.com/c/1285129 > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56881} CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_arm64_dbg_recipe TBR=mlippautz@chromium.org Bug: chromium:893460 Change-Id: Icc45fd091c33f7df805842a70236b79b14756f52 Reviewed-on: https://chromium-review.googlesource.com/c/1297300 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#56965}
-