summaryrefslogtreecommitdiffstats
path: root/base/trace_event/process_memory_dump.h
Commit message (Collapse)AuthorAgeFilesLines
* base: Remove some unnecessary const scoped_refptr<>&.vmpstr2016-03-181-1/+1
| | | | | | | | | | | | | This patch removes some unnecessary const scoped_refptr<>&. It replaces some instances with a copy of scoped_refptr, followed by a move. Other instances, it passes a raw non-owning pointer. R=danakj BUG=589044 Review URL: https://codereview.chromium.org/1800743003 Cr-Commit-Position: refs/heads/master@{#382043}
* Use sysctlbyname() to get kernel page size.pkl2016-03-161-4/+7
| | | | | | | | | | | | | | | | | | | | | This allows enabling of COUNT_RESIDENT_BYTES_SUPPORTED tests. It is also possible to change iOS' implementation of base::GetPageSize() implementation to use sysctlbyname() instead of getpagesize(), but since it is only the use of mincore() that requires the use of kernel page size, it is better to have a smaller change than a more invasive change to base::GetPageSize(). I'm concerned that changing GetPageSize() to return 4KB (what sysctlbyname returns) instead of 16KB (what getpagesize returns) may have some unknown side effects. BUG=542671 Review URL: https://codereview.chromium.org/1793943002 Cr-Commit-Position: refs/heads/master@{#381475}
* tracing: Make ConvertableToTraceFormat move-onlyprimiano2016-02-291-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary. This CL: - Makes TraceEvent ownership a move-only scoped_ptr. - Makes ConvertableToTraceFormat (CTTF) itself move-only scoped_ptr. - Updates all the codebase that uses CTTF in TRACE_EVENT macros to use move-only semantics. Background: Historically ConvertableToTraceFormat (CTTF) was RefCounted. The main reason seems to be supporting monitoring mode (now deprecated) where tracing needed to copy TraceEvents without flushing the TraceLog. Not what monitoring mode is gone, there is no reason why TraceEvent(s) should not be move-only. Unfortunately CTTF being RefCounted exposed that implementation detail to its public interface. Fortunately, most of the codebase doesn't care about the fact that CTTF is RefCounted. The only exceptions are: 1. Memory-infra heap profiler {StackFrame,TypeInfo}Deduplicator 2. cc::Layer DebugInfo 1) Is addressed creating a proxy class which delegates the CTTF methods to the duplicators inside MDSessionState. Essentially it makes the CTTF metadata events shared co-owners of the MDSessionState. 2) After an offline chat with danakj@, it seems OK to make DebugInfo(s) moved scoped_ptr (as opposite as copied), moving the ownership to the active layer and keeping a raw ptr into the pending layer. BUG=559117 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel TBR=thakis,jochen,tbarzic,mnaganov,skyostil Review URL: https://codereview.chromium.org/1717283003 Cr-Commit-Position: refs/heads/master@{#378263}
* tracing: memory-infra cleanup post-C++11 + test coverageprimiano2016-02-221-9/+7
| | | | | | | | | | | | | | In the context of a bigger refactoring I realized that: - ProcessMemoryDump memory management can be simplified now that we have C++11 moving semantics. - A heap-profiler code path was untested. - Using SmallMap in our big memory dumps it's like drinking diet lemonade with deep fried fish and chips. Also taking the occasion for some minor cleanups and clang-format. Review URL: https://codereview.chromium.org/1718173002 Cr-Commit-Position: refs/heads/master@{#376750}
* Add support for CountResidentBytes in windowsssid2016-01-211-1/+2
| | | | | | | | | | | | | | This CL adds support for CountResidentBytes on windows. The QueryWorkingSetEx gives the information about pages in range of given address that are in the working set of the process. We use that to count the resident bytes similar to how it's done in other platforms. BUG=570655 Review URL: https://codereview.chromium.org/1573313002 Cr-Commit-Position: refs/heads/master@{#370689}
* [tracing] Add method to create "weak" global dumpsssid2016-01-211-0/+9
| | | | | | | | | | | | | | | | | | | | | | The renderer process could add memory dumps that are known to be non-existent in the browser. To resolve this issue, a notion of "weak" global allocator dump is introduced so that the renderer could tell it is unsure of the existence of the dump. A weak dump will be removed in the UI unless at least one process creates a non-weak global dump with the same guid. This would mark the existence of the memory. Sample use case: The browser creates a non-weak global dump and a renderer process creates a weak global dump for discardable segments. This represents the fact that the renderer doesn't know whether a segment is or isn't present in memory. BUG=570655 Review URL: https://codereview.chromium.org/1583483002 Cr-Commit-Position: refs/heads/master@{#370683}
* Switch to standard integer types in base/trace_event/.avi2015-12-241-0/+4
| | | | | | | | | BUG=138542 TBR=dsinclair@chromium.org Review URL: https://codereview.chromium.org/1546033002 Cr-Commit-Position: refs/heads/master@{#366798}
* [iOS] Disable COUNT_RESIDENT_BYTES_SUPPORTED.sdefresne2015-10-301-1/+3
| | | | | | | | | | | | COUNT_RESIDENT_BYTES_SUPPORTED is disabled on iOS as it causes memory corruption on iOS 9.0+ devices. Note that this was only caught on bots downstream as we cannot run real device bots upstream. BUG=542671 Review URL: https://codereview.chromium.org/1425933002 Cr-Commit-Position: refs/heads/master@{#357079}
* [Tracing] Introduce HeapDumpWriter helper classruuda2015-10-271-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The heap profiler in chrome://tracing keeps track of allocations in an |AllocationRegister|. When a heap dump is requested, a summary of the allocation register should be written to the trace log. (It is not possible to dump every single allocation, some processes have peeks as high as 400k outstanding allocations.) The |HeapDumpWriter| class analyzes all allocations and writes a condensed heap dump to the trace log. At the moment the logic is very simple. All allocations are grouped by backtrace, and the number of bytes allocated per backtrace is written. In the future this will be extended with the ability to group by different pieces of context. Furthermore, a smarter algorithm can be introduced that writes as much information as possible given a fixed budget of trace log space. The heap dump writer is designed to be independent of the |StackFrameDeduplicator|. There could be a deduplicator per dump provider, or a global deduplicator. By taking it as an argument, the dumper works either way. BUG=524631 Review URL: https://codereview.chromium.org/1419633004 Cr-Commit-Position: refs/heads/master@{#356282}
* [tracing] Display the resident size of the discardable memory segmentsssid2015-10-121-0/+14
| | | | | | | | | | | | | This CL displays the total size of the resident pages of the discardable memory segments. The resident page is counted using mincore system call in posix systems. It is not implemented in other platforms. TBR=avi@chromium.org BUG=528632 Review URL: https://codereview.chromium.org/1375963007 Cr-Commit-Position: refs/heads/master@{#353546}
* [tracing] Expose a GetOrCreateAllocatorDump for memory tracingprimiano2015-10-051-0/+3
| | | | | | | | | | | Small non-functional refactor in preparation of upcoming CLs. BUG= TBR=reed@google.com Review URL: https://codereview.chromium.org/1387833004 Cr-Commit-Position: refs/heads/master@{#352453}
* [tracing] Non-functional refactor of memory dump arg namesprimiano2015-09-141-6/+2
| | | | | | | | | | | | | | | | This CL is just cleaning up the inconsistencies accumulated w.r.t. of names used in the TraceConfig vs enum names in the codebase. Also this simplifies the complex and unnecessary wrapping in of the level of details argument in the RequestGlobalMemoryDump() API. BUG= TBR=jochen@chromium.org,reed@google.com Review URL: https://codereview.chromium.org/1337943003 Cr-Commit-Position: refs/heads/master@{#348715}
* [tracing] Non functional refactor of MemoryInfra headersprimiano2015-07-061-24/+25
| | | | | | | | | | | | This is just cleaning up and improving readability of MemoryInfra APIs. Moves the most typically used APIs first and removes some stale internal details. BUG=466141 Review URL: https://codereview.chromium.org/1206393002 Cr-Commit-Position: refs/heads/master@{#337375}
* [tracing] API to express memory suballocation and cross-process sharingprimiano2015-06-031-4/+23
| | | | | | | | | | | | | | | | | | - Add a {Get,Create}SharedGlobalAllocatorDump to create shared nodes that can be referenced by several processes (concrete use case: reporting different details about the same shared memory segment from different processes) - Add a utility AddSuballocation method to express suballocation. Under the hoods it creates an anonymous node on the target allocator and establishes an ownership relationship with that. For more details and use cases see the design doc attached to the bug. BUG=492102 Review URL: https://codereview.chromium.org/1156023007 Cr-Commit-Position: refs/heads/master@{#332581}
* [tracing] Add guid overload to CreateAllocatorDumpprimiano2015-05-291-0/+7
| | | | | | | | | | | Small follow-up to crrev.com/1161813004 which forgot to add the overloaded ctor. BUG=492102 Review URL: https://codereview.chromium.org/1157433005 Cr-Commit-Position: refs/heads/master@{#331962}
* [tracing] Extend memory dump API with graphsprimiano2015-05-281-0/+28
| | | | | | | | | | | | | | | This CL allows to express ownership relationships between MemoryAllocatorDump(s). Ownership edges are the building block to express suballocation, sharing (co-ownership) and cross-process-sharing (the latter might require an extra CL to introduce global nodes). See the related bug for the design doc and concrete use cases. BUG=492102 Review URL: https://codereview.chromium.org/1161813004 Cr-Commit-Position: refs/heads/master@{#331768}
* [tracing] Add Clear() method to ProcessMemoryDumpprimiano2015-05-261-0/+4
| | | | | | | | | | | | | | | | | | This CL exposes a simple Clear() method that removes all the MemoryAllocatorDump(s) from a given ProcessMemoryDump instance and allows the PMD to be reused. The concrete use case for this is the BlinkGC dumper, which is constrained to snapshot memory at a higher peace than what required for the dumps (on every GC). This removes the burden from the dumper to deal with any dynamic memory management (read: the dumper doesn't have to free and re-new a PMD for each GC) BUG=491248 Review URL: https://codereview.chromium.org/1156133002 Cr-Commit-Position: refs/heads/master@{#331407}
* [tracing] Add support to pre-load and merge ProcessMemoryDump(s).primiano2015-05-211-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Allows MemoryDumpProvider(s) with dump-time constraints (mostly GC allocators) to create out-of-band MemoryAllocatorDump(s) and merge them during the onMemoryDump callback. So far, the architecture of MemoryDumpProvider expected to never instantiate ProcessMemoryDump(s) directly, but just fill up the one passed as argument to the onMemoryDump(ProcessMemoryDump*) callback. This, however, doesn't cover the cases of dumpers that cannot dump at arbitrary times (i.e. during onMemoryDump callback) and need to pre-fill the dump stats before the actual callback comes. A concrete case of this are dump providers for garbage-collected allocators (specifically BlinkGC) where some of the stats can be collected only during the GC. BUG=466141 Review URL: https://codereview.chromium.org/1151603004 Cr-Commit-Position: refs/heads/master@{#330924}
* [tracing] Simplify the MemoryAllocatorDump APIprimiano2015-04-281-14/+6
| | | | | | | | | | | | | | | | | | | | | | | Up until now the API surface of the MemoryAllocatorDump has been strongly typed, enforcing three basic counters (physical_size, allocated_objects_count and allocated_objects_size) + arbitrary extra attributes. This CL simplifies the MAD interface as follows: - Remove the two argument (allocator_name, heap_name) in favor of a simpler and single argument absolute_name (e.g., CreateAllocatorDump("v8/isolate1/heap2") instead of CreateAllocatorDump("v8", "isolate1/heap2")) - Remove the storngly typed properties in favor of a generic Add(attribute_name, type, units, value) method. - Add helper methods MAD.AddScalar() and AddString(). - Rewrite the existing dumpers to use the new simpler API. - Fix the tests. BUG=466141 Review URL: https://codereview.chromium.org/1105143003 Cr-Commit-Position: refs/heads/master@{#327310}
* [tracing] Simplify design of MemoryAllocatorDumpprimiano2015-04-211-10/+22
| | | | | | | | | | | | | | | | | | | | This is a follow-up to crrev.com/1084213003 (which introduces the MemoryAllocatorAttributesTypes) and crrev.com/1093953002 (which introduces the shared MemoryDumpSessionState). The design of MemoryAllocatorDump is simplified, as follows: MemoryAllocatorDump(s) are uniquely identified witin a ProcessMemoryDump by an allocator_name and a heap_name. The former acts as a type, and determines the types of the attributes. The latter defines the rest of the dump name. As far as the trace is concerned, the allocator dumps will be identified the trace by an absolute path, that is: allocator_name/heap/subheap. BUG=466141 Review URL: https://codereview.chromium.org/1095003002 Cr-Commit-Position: refs/heads/master@{#325994}
* [tracing] Introduce MemoryDumpSessionStateprimiano2015-04-211-3/+11
| | | | | | | | | | | | | | | | MemoryDumpSessionState is a container class to hold objects that need to be shared between all the ProcessMemoryDumps for all the lifetime of a tracing session. A concrete use case is going to be represented by the dictionary of allocator attributes types, that will be dumped once by the MemoryDumpProviders into the MemoryDumpSessionState when the trace starts and will be accessed when generating the final trace data. BUG=466141 Review URL: https://codereview.chromium.org/1093953002 Cr-Commit-Position: refs/heads/master@{#325987}
* [tracing] Refactor MemoryDumpManager for upcoming multiprocess dumpsprimiano2015-03-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This CL introduces minimal code change with no functional behavioral changes to the MemoryDumpManager, in particular: - Move the definition of structs and types used to request memory dumps to a separate file (memory_dump_request_args.h). Rationale: these structs will be used in upcoming CLs by IPCs and this header avoids to include the full MDM header and breaks include loops. - Rename the RequestDumpPoint to RequestGlobalDumpPoint, to make it explicit that the dump will be global. - Turn the internal dump request parameters into a struct (MemoryDumpRequestArgs). This will be serialized over IPC and serves as an extensions point for the future (add extra dumpe parameters without having to rewrite all the IPC / message filters call sites) More context and design doc are available in the attached BUG. BUG=462930 Review URL: https://codereview.chromium.org/1045613002 Cr-Commit-Position: refs/heads/master@{#323033}
* [tracing] Introduce support for userland memory allocators dumps.primiano2015-03-191-0/+30
| | | | | | | | | | | | | | | This introduces the MemoryAllocatorDump which defines the ground data model that every allocator MemoryDumpProvider must comply with in order to get a coherent snapshot of the various allocators inside the trace. Furthermore, MemoryDumpProvider(s) can specify further attributes that will be attached to each dump point using the MemoryAllocatorAttributes map. BUG=466141 Review URL: https://codereview.chromium.org/987043003 Cr-Commit-Position: refs/heads/master@{#321368}
* [tracing] memory maps dump provider skeletonprimiano2015-02-241-0/+8
| | | | | | | | | | | | | This CL introduces the skeleton (data model and dump provider stub) for snapshotting memory maps into the traces (via MemoryDumpManager). In the next CLs, the actual code to retrieve the data for the various OSs (or at least some of them) will be introduced. BUG=460884 Review URL: https://codereview.chromium.org/928723004 Cr-Commit-Position: refs/heads/master@{#317821}
* [tracing] Add a dump provider to dump process memory totals.primiano2015-02-201-12/+19
| | | | | | | | | | | This CL introduces a dump provider which is able to capture the process Resident Set Size and the corresponding unittest. BUG=442731,458295 Review URL: https://codereview.chromium.org/934323002 Cr-Commit-Position: refs/heads/master@{#317336}
* [tracing] Introduce memory tracing skeleton.primiano2015-02-171-0/+37
This is the first step towards the introduction of memory as a metric in chromium tracing. This change introduces the core memory dump manager which will coordinate the memory dumps. Specifically, the following concepts are introduced by this CL: - memory_dump_manager: the front-end interface exposed to the rest of the codebase to create memory dump points. - memory_dump_provider: the contract interface that memory dumpers need to expose in order to coordinate with the manager. This CL does NOT expose any user-visible tracing functionality. BUG=458295 Review URL: https://codereview.chromium.org/933613002 Cr-Commit-Position: refs/heads/master@{#316700}
generated by cgit v1.1 at 2024-06-08 17:04:15 +0000