Collection and representation of program call stacks

Abstract

Techniques disclosed herein implement an improved format for sending a call stack, referred to herein as a stack, from a machine to a stack analysis service. In addition, the techniques implement an improved way for stack analysis services to represent a large number of stacks. The improved format enables collection of a large number of stacks (e.g., millions or even trillions of stacks) to be more efficient. The improved representation of a large number of stacks enables analysis to be more efficient. Thus, the techniques described herein reduce the carbon footprint of an organization for operating a set of machines, since fewer networks, storage, and / or processing resources are required to collect and analyze a large number of stacks.

Description

Background Art

[0001] Developers of computer programs and / or operators of a large group of machines (e.g., servers, personal computers, Internet of Things (IoT) devices) often analyze call stacks to identify the most frequently used programming elements (e.g., subroutines, functions, statements), determine system costs regarding modifying programming elements, identify which programming elements use most of the processing time, implement stack traces for debugging purposes, etc. A call stack is a data structure that stores information about the flow of an executing computer program. More specifically, a flow captures calls from one programming element to another programming element. A flow that can be added to a call stack includes a dedicated location (e.g., a memory block) in memory that can be used by a compiler and / or a processing unit (e.g., a central processing unit (CPU)). A dedicated location is typically represented by a set of addresses (e.g., addresses "0000"-"9999").

[0002] Thus, a call stack includes multiple streams in a defined sequence (e.g., stream A includes a call to stream B, stream B includes a call to stream C, and so on). Streams in a call stack are represented by addresses (e.g., stream A is represented by stream address "4096"). Although a call stack can include any number of streams, relatively small call stacks typically include eight to twelve streams, while relatively large call stacks typically include thirty to one hundred streams. It is noteworthy that a call stack may alternatively be referred to as an execution stack, a program stack, a control stack, a runtime stack, or a machine stack, and is often referred to simply as a stack.

[0003] Typically, the above analysis needs to be performed on machines across a fleet within an organization. Depending on the size of the organization, a large number of stacks may need to be collected and stored. For example, a cloud provider with multiple data centers collects and analyzes over trillions of stacks per day. Such collection and analysis may result in a large carbon footprint for the organization due to the energy used to operate resources to collect, store, and / or analyze a large number of stacks. Summary of the invention

[0004] The disclosed techniques implement an improved format for sending call stacks (referred to herein as stacks) from a machine to a stack analysis service. In addition, these techniques implement an improved way for the stack analysis service to represent large numbers of stacks. The improved format enables the collection of large numbers of stacks (e.g., millions or even trillions of stacks) to be more efficient. The improved representation of large numbers of stacks enables analysis to be more efficient. Therefore, the techniques described herein reduce the carbon footprint of an organization operating a group of machines because fewer network, storage, and / or processing resources are required to collect and analyze large numbers of stacks.

[0005] The format used locally by the machine to send the stack to the stack analysis service uses address offsets to represent flows in the stack. As described above, a stack is a data structure that stores information about the flow of a computer program being executed. More specifically, a flow captures a call from one programming element (e.g., a subroutine, a function, a statement) to another programming element. Thus, a stack includes a sequence of flows (which may alternatively be referred to herein as a sequence of flows).

[0006] As described above, streams that can be added to the stack reside in dedicated locations (e.g., memory blocks) in memory that can be used by a compiler and / or a processing unit (e.g., a central processing unit (CPU)). The dedicated locations are typically represented by a set of addresses (e.g., addresses "0000"-"9999"). Streams in the stack are typically represented by addresses (e.g., stream A is represented by stream address "4096").

[0007] The format used to send a stack from a machine to the stack analysis service uses an actual address to represent the first stream in the sequence of streams contained in the stack. This actual address is used as the baseline address of the stack. However, the format does not use an actual address to represent streams after the first stream in the sequence of streams. Instead, the format uses an address offset to represent each stream after the first stream in the sequence of streams. The address offset is the difference between the address of the current stream and the address of the previous stream that called the current stream. For example, the address offset of stream B is the difference between the actual address of stream B and the actual address of stream A, the address offset of stream C is the difference between the actual address of stream C and the actual address of stream B, and so on.

[0008] The use of address offsets enables saving of storage space and / or enables increasing the compression ratio associated with the transmission of the stack, because the value of the address offset is usually smaller than the value of the actual address. The value of the address offset is usually smaller than the value of the actual address, because the operating system and / or the compiler strive to obtain a high storage locality with respect to the related programming elements. That is, programming elements that frequently call each other are usually stored in memory close to each other (e.g., close addresses), for example, by the operating system and / or the compiler.

[0009] In various examples, these techniques further improve the efficiency with which the stack is sent by variable bit encoding the address offsets representing the streams in the stack. That is, the processing power used to prepare the stack for transmission is reduced by using variable bit encoding instead of traditional compression techniques (e.g., DEFLATE data compression, ZIP data compression), because traditional compression techniques require scanning previously seen data and looking for duplicate portions of the data. Therefore, variable bit encoding of address offsets, rather than using the entire address associated with a machine, operating system, and / or CPU configured for sixty-four bit operations, allows for lower processing costs, which is ideal in environments that are sensitive to power consumption and carbon footprint (e.g., data center operators, cloud providers).

[0010] After a machine packages a stack locally for transport using a format that employs address offsets and / or variable bit encoding, a stack analysis service collects the stack and generates a flow identifier for each flow in the stack. The stack analysis service is configured to recalculate the address of each flow in the stack using a baseline address representing a first flow and an address offset representing a flow after the first flow. The addresses for a particular flow are consistent or identical across machines in a cluster, which enables improved representation of a large number of stacks, as further described herein. For example, if flow A is stored at address "4032" of one machine in a cluster, flow A is stored at address "4032" across machines in the cluster.

[0011] Once the stacks are collected by the stack analysis service, the stacks are represented in an efficient manner that reduces the use of storage and processing resources. As described herein, the stack analysis service is configured to generate a graph of a set of stacks (e.g., stacks in a stack file). In one example, the stack analysis service is configured to receive a stack file from each machine in a cluster of machines. In another example, the stack analysis service is configured to receive a single stack file from a predefined set of machines (e.g., two machines, three machines, ten machines).

[0012] The graph includes multiple entries, each of which represents a unique stream sequence. The stack analysis service reads the stacks in the stack file sequentially (e.g., one after another). For the first stack read sequentially and / or for the first stream sequence encountered, the stack analysis service adds an entry to the graph. Similarly, the entry represents the stream sequence in the first stack read sequentially from the stack file. For each stack read sequentially from the stack file after the first stack, the stack analysis service uses the stream identification to determine whether the stream sequence contained in the stack currently being read sequentially from the stack file (i.e., the "current" or "remaining" stack) matches the stream sequence in a previous stack that has been read sequentially from the stack file.

[0013] If the flow sequence in the current stack matches the flow sequence in the previous stack, meaning the graph already contains an entry for the matching flow sequence, the stack analysis service increases the weight value of the entry. The weight value represents the number of times the flow sequence appears in different stacks. If the flow sequence in the current stack does not match the flow sequence in the previous stack, meaning the graph does not yet contain an entry for the flow sequence in the current stack, the stack analysis service adds a new entry to the graph.

[0014] The stack analysis service may additionally be configured to use pointers from a flow identifier (e.g., flow node) in one entry in the graph to the same flow identifier in a different entry in the graph. For example, in response to determining that a flow sequence in a current stack does not match a flow sequence in a previous stack, the stack analysis service searches for flow identifiers in existing entries of the graph that match a flow identifier in a new entry added to the graph. In the event of a match, the stack analysis service adds a pointer from the flow in the new entry to the matching flow in the existing entry.

[0015] By representing the stack of stack files in a graph using the number of times each unique sequence of flows is encountered in the stack, deduplication of data can be enabled. Data deduplication can be further performed by using pointers between matching flows in different entries. Thus, a graph having weight values ​​for each entry and / or pointers between matching flows in different entries allows for more efficient storage and / or more efficient transmission from one location (e.g., one server) to another location (e.g., another server).

[0016] When the graph is stored for analysis (e.g., written to disk), the entries in the graph are sorted according to decreasing weight values. This ensures that entries that are seen more often in the stack of stack files (e.g., entries with higher hit counts) and are generally more important or meaningful from an analysis perspective are shown first when the graph is read from disk. For example, a clear depiction of the performance of the cluster is apparent even when a small percentage of the data in the graph has been read.

[0017] In various examples, a weight value threshold can be used to prune the graph. That is, the stack analysis service is configured to determine that the weight value of an entry in the graph fails to meet the weight value threshold (e.g., the weight value is lower than the weight value threshold). Based on this determination, the stack analysis service removes the entry from the graph. This can further improve the efficiency of sending, storing and / or processing stack data in the graph because rarely encountered entries can be removed. Typically, the growth of the stack data to be represented (e.g., the increase in the stack) is driven by rarely occurring flow sequences (e.g., flow sequences that only occur once). If these rarely occurring flow sequences are not pruned, the amount of stack data to be processed and stored may grow indefinitely, requiring a large amount of resources.

[0018] An additional benefit of using entry weights is that graphs (e.g., pruned graphs) can be efficiently merged with each other. For example, the weight values ​​for matching entries in two graphs can be combined and represented in a merged graph. This merging can occur recursively as the collected stack data increases, and due to this recursive merging, a graph can represent a large number of stack files and / or stacks. Ultimately, this alleviates the need to maintain a database to store a large number of stacks and / or stack files. On the contrary, via the use of graphs, pruned graphs, and / or merged graphs, the analysis of stacks can be expanded. For example, due to the reduction in space and the removal of restrictions, a graph of stacks collected from a cluster of client machines can be placed in a storage account allocated by the client.

[0019] In various examples, the graph may also include playback data. The playback data includes a timestamp associated with the execution of the flow, and attributes associated with the execution of the flow. Example attributes include a process identifier (PID) and / or a thread identifier (TID). The timestamp and attributes may be used to playback the execution of the flow at a specific machine.

[0020] By reading the following detailed description and viewing the associated drawings, other features and technical benefits in addition to the features and technical benefits explicitly described above will be apparent. This summary is intended to introduce in a simplified form a series of concepts further described in the specific embodiments below. This summary is not intended to identify the key or essential features of the claimed subject matter, nor is it intended to be used as an auxiliary means for determining the scope of the claimed subject matter. For example, the term "technology" may refer to (multiple) systems, (multiple) methods, computer-readable instructions, (multiple) modules, algorithms, hardware logic and / or (multiple) operations as allowed by the above context and the entire document. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The detailed description is described with reference to the accompanying drawings. In the drawings, the leftmost digit(s) of a reference number identifies the drawing in which the reference number first appears. The same reference numbers in different drawings indicate similar or identical items.

[0022] Figure 1 An example environment is illustrated in which a machine implements an improved format for sending a stack to a stack analysis service and / or in which a stack analysis service can more efficiently represent a large number of stacks in a graph.

[0023] Figure 2 An example diagram is shown that captures technical benefits of using an address offset format and / or variable bit encoding when sending a stack from a machine to a stack analysis service.

[0024] Figure 3A An example diagram capturing technical benefits of using a graph to represent a stack having entries and / or entry weight values ​​is shown.

[0025] Figure 3B An example diagram capturing technical benefits of using a graph to represent a stack with entries, entry weight values, and / or pointers is shown.

[0026] Figure 4 An example diagram of pruning a graph representing a stack having entries, entry weight values, and / or pointers is shown.

[0027] Figure 5A An example graph aimed at merging two pruned graphs is shown.

[0028] Figure 5B Shown in Figure 5A An example graph showing the merged graph after merging two pruned graphs.

[0029] Figure 6 An example graph is shown in which playback data is associated with each node in the graph.

[0030] Figure 7 is an example flow chart illustrating aspects of a machine-implemented method for representing a stack using a format that includes address offsets.

[0031] Figure 8 is an example flow chart illustrating aspects of a method implemented by a stack analysis service to generate a graph representing a stack in a stack file.

[0032] Fig. 9 is a computer architecture diagram showing an illustrative computer hardware and software architecture for a computing system capable of implementing aspects of the techniques and technologies presented herein. DETAILED DESCRIPTION

[0033] The techniques disclosed herein implement an improved format for sending call stacks (referred to herein as stacks) from a machine to a stack analysis service. In addition, these techniques implement an improved way for the stack analysis service to represent large numbers of stacks. The improved format enables the collection of large numbers of stacks (e.g., millions or even trillions of stacks) to be more efficient. The improved representation of large numbers of stacks enables analysis to be more efficient. Thus, the techniques described herein reduce the carbon footprint of an organization operating a group of machines because fewer network, storage, and / or processing resources are required to collect and analyze large numbers of stacks. Figures 1 to 9 Describes various examples, scenarios, and aspects for implementing the techniques described herein.

[0034] Figure 1An example environment 100 is shown in which machines 102(1-N) implement an improved format for sending stacks to a stack analysis service 104 and / or in which the stack analysis service 104 can more efficiently represent a large number of stacks in a graph. As described above, the machines 102(1-N) can include servers or other types of machines (e.g., laptop devices, tablet devices, smart phone devices, Internet of Things (IoT) devices) that include a cluster 106 configured and / or operated by an organization (e.g., an operator of a public cloud data center). The stack analysis service 104 can be executed, for example, on one or more servers.

[0035] Each machine 102(1-N) includes at least one central processing unit (CPU) 108(1-N). Each CPU 108(1-N) is configured to generate a corresponding stack 110(1-N) over a period of time (e.g., seconds, minutes, hours). A stack is a data structure that stores information about the flow of a computer program being executed by one of the CPUs 108(1-N). More specifically, a flow captures a call from one programming element (e.g., a subroutine, a function, a statement) to another programming element in a computer program. A flow added to a stack 110(1-N) by a CPU 108(1-N) includes a dedicated location in memory (e.g., a memory block). A dedicated location is typically represented by a set of addresses (e.g., addresses "0000"-"9999"). Thus, each stack 110(1-N) includes a sequence of flows and flows in a stack are represented by addresses.

[0036] It may be beneficial for an operator of the cluster 106 to collect and analyze the stacks 110(1-N) for a particular purpose. For example, the stack analysis service 104 may collect and analyze the stacks 110(1-N) to identify the most commonly used programming elements, determine the system cost associated with modifying programming elements, identify which programming elements use the most processing time, implement stack traces for debugging purposes, etc. To improve the manner in which the stacks 110(1-N) are collected and represented for analysis, the stack analysis service 104 includes a stack file collection module 112, a graph generation module 114, a graph pruning module 116, a graph merging module 118, and a stack analysis module 120, each of which will be discussed further herein. The functions described herein in association with the modules shown may be performed by a fewer number of modules or a greater number of modules.

[0037] To improve the collection of stacks 110 (1-N), the stack file collection module 112 uses an address offset format 122 to represent flows in a stack. The stack file collection module 112 pushes the address offset format 122 to the machines 102 (1-N) in the cluster 106. The machines 102 (1-N) are configured to locally generate a stack file 124 (1-N) that includes the stacks 110 (1-N) most recently configured by the CPUs 108 (1-N). The stack file includes at least one stack. The stack file collection module 112 can be configured to collect the stack files 124 (1-N) according to a schedule 126 established based on various factors (e.g., once every hour, every two hours, once a day). Additionally or alternatively, the stack file collection module 112 can be configured to collect the stack files 124 (1-N) based on the occurrence of an event 128 (e.g., a system failure, a network attack).

[0038] Prior to sending the stack file 124(1-N) to the stack analysis service 104, based on a schedule 126 and / or based on the occurrence of an event 128, the machine 102(1-N) is configured to generate and / or format the stack 110(1-N) in an address offset format 122. The address offset format 122 uses an actual address to represent the first stream in the stack sequence. The actual address can be referred to as the baseline address of the stack. However, the address offset format 122 does not use an actual address to represent the streams after the first stream in the stack sequence. Instead, the address offset format 122 uses an address offset to represent each stream after the first stream in the sequence. The address offset is the difference between the address of the current stream and the address of the previous stream that called the current stream.

[0039] In various examples, these techniques further improve the efficiency with which the stack is sent by variable bit encoding address offsets that represent streams in the stack. That is, the processing power used to prepare the stack for transmission is reduced by using variable bit encoding rather than traditional compression techniques (e.g., DEFLATE data compression, ZIP data compression), because traditional compression techniques require scanning previously seen data and looking for duplicate portions of the data. Therefore, variable bit encoding of address offsets, rather than using entire addresses associated with a machine, operating system, and / or CPU configured for sixty-four-bit operations, allows for lower processing costs to be achieved, which is ideal in environments that are sensitive to power consumption and carbon footprint (e.g., data center operators, cloud providers). Figure 2 Examples of technical improvements provided by address offset format 122 and / or variable bit encoding are provided in.

[0040] After the machine 102(1-N) locally prepares the stack 110(1-N) for transmission via the stack file 124(1-N) using the address offset format 122 and / or the variable bit encoding, the stack file collection module 112 passes the stack file 124(1-N) to the graph generation module 114. The graph generation module 114 is configured to generate a flow identifier 130 for each flow in the stack, as described herein with respect to Figure 2 Further described. In addition, the graph generation module 114 is configured to generate a graph that represents the stack in a manner that reduces the use of storage and processing resources. For example, the graph generation module 114 generates a graph 132 having entries, weights, and / or pointers for each stack file 124 (1-N), as described herein with respect to Figure 3A or Figure 3B As further described. The graph includes a plurality of entries, wherein each entry represents a unique flow sequence. In addition, each entry in the graph includes a weight value that tracks the number of times the unique flow sequence appears in a single stack file or a stack of multiple stack files. Although Figure 1 The stack files 124 ( 1 -N) are shown collected from each machine 102 ( 1 -N) in the cluster 106 , but the stack files may be collected from a predefined group of machines (eg, two machines, three machines, ten machines).

[0041] Deduplication of data is enabled by representing a stack of stack files in a graph 132 with entries, weights, and / or pointers. Thus, the graph allows for more efficient storage and / or more efficient transmission from one location (e.g., one server) to another location (e.g., another server).

[0042] In various examples, graph 132 may be pruned using weight value threshold 134. That is, graph pruning module 116 is configured to determine that a weight value of an entry in graph 132 fails to satisfy weight value threshold 134 (e.g., the weight value is below the weight value threshold). Based on this determination, graph pruning module 116 removes entry 136 from the graph, as described herein with respect to Figure 4 As described. This pruning can further improve the efficiency of sending, storing and / or processing the stack data in the graph because rarely encountered entries can be removed. Typically, the growth of the stack data to be represented (e.g., the increase of the stack) is driven by rarely occurring flow sequences (e.g., flow sequences that occur only once). If these rarely occurring flow sequences are not pruned, the amount of stack data to be processed and stored may grow indefinitely, requiring a large amount of resources.

[0043] An additional benefit of using entry weights is that graphs (e.g., pruned graphs) can be efficiently merged with each other. For example, assuming that two different stack files 124(1) and 124(2) are provided with two different graphs, the graph merging module 118 can obtain the weight values ​​for matching entries in the two different graphs and add them together to calculate the combined weight value of the merged graph 138. As the collected stack data increases (e.g., as more and more stack files 124(1-N) are received), this merging can occur recursively. Due to this recursive merging, the graph merging module 118 can pass a single graph 140 representing a large number of stacks 110(1-N) and / or stack files 124(1-N) to the stack analysis module 120. Alternatively, the graph merging module 118 can efficiently pass (e.g., send, transmit) a single graph to different customers (e.g., user devices, clients, tenants, customers). Ultimately, this alleviates the need to maintain a dedicated database for storing, processing, and managing stacks 110(1-N) and / or stack files 124(1-N). Instead, analysis of the stack may be extended via the use of graphs, graph pruning, and / or graph merging.

[0044] Figure 2 An example diagram is shown that captures the technical benefits of using address offset format and / or variable bit encoding when sending a stack from a machine to a stack analysis service. Figure 2 As shown in the upper portion of , a conventional method using the actual address format 202 is used to send a stack 204. The stack 204 includes a stream A represented by an address "4096" 206, a stream B represented by an address "4000" 208, a stream C represented by an address "3800" 210, a stream D represented by an address "4024" 212, and a stream E represented by an address "1024" 214.

[0045] In preparing stack 204 for transmission, when machines 102(1-N) are sixty-four-bit machines, each real address uses eight bytes of space, as shown via elements 216, 218, 220, 222, and 224. Thus, when real address format 202 is used, a transmission of stack 204 consumes forty bytes 226.

[0046] However, as mentioned above, the compiler and / or CPU strives to achieve high locality with respect to storage flows that frequently call each other. Therefore, Figure 2The lower half of the diagram shows the technical benefits achieved by sending the same stack 204 using the address offset format 122. Using the address offset format 122, stream A in the stack 204 is still represented by the baseline-address "4096" 206. However, stream B is represented by the difference between the address "4000" of the current stream and the address "4096" of the previous stream, or "-96" 228. Stream C is represented by the difference between the address "3800" of the current stream and the address "4000" of the previous stream, or "-200" 230. Stream D is represented by the difference between the address "4024" of the current stream and the address "3800" of the previous stream, or "+224" 232. Stream E is represented by the difference between the address "1024" of the current stream and the address "4024" of the previous stream, or "-300" 234.

[0047] Note that when address offsets are used, one bit is used to indicate a positive or negative difference or increment. When preparing the stack 204 for transmission via the use of variable bit encoding 236, the baseline address "4096" uses two bytes of space 238. The address offset "-96" uses one byte of space 240. The address offset "-200" uses two bytes of space 242. The address offset "+224" uses two bytes of space 244. And the address offset "-3000" uses two bytes of space 246. Therefore, transmitting the stack 204 using the address offset format 122 consumes nine bytes 248, which is a significant improvement over the forty bytes 226 used via the actual address format 202.

[0048] Figure 3A An example diagram is shown that captures the technical benefits of using a graph 132 representing a stack having entries, entry weight values, and / or pointers. As described above, before generating the graph 132, the graph generation module 114 is configured to recalculate the address of each flow in the stack using a baseline address representing a first flow and an address offset representing a flow after the first flow. The address is used as a flow identification (ID) (e.g., a node ID). For example, recall that Figure 2 , the graph generation module 114 uses the baseline address "4096" and the address offset "-96" to recalculate the address "4000" of the stream B 228. In addition, the graph generation module 114 uses the recalculated address "4000" and the address offset "-200" to recalculate the address "3800" of the stream C 230. The addresses used to identify a particular stream are consistent or the same across the machines 102 (1-N) of a cluster, which enables improved representation of a large number of stacks in the graph 132.

[0049] The graph generation module 114 is configured to read the stack files 302 sequentially (e.g., one stack at a time) when generating the graph 132. Figure 3AIn the example of , there are ten stacks 304, 306, 308, 310, 312, 314, 316, 318, 320 and 322 in the stack file 302. As shown, Figure 132 includes multiple entries 324, 326, 328, 330, which are added based on the stacks read sequentially. In this example, entry 324 is identified by a stream sequence (0, 1, 2, 3), entry 326 is identified by a stream sequence (4, 2, 3), entry 328 is identified by a stream sequence (5, 6, 3), and entry 330 is identified by a stream sequence (7, 8, 6, 3). Therefore, each entry 324, 326, 328, 330 represents a unique stream sequence.

[0050] For the first stack 304 sequentially read from the stack file 302, the graph generation module 114 adds entries to the graph. Specifically, the first stack 304 includes a stream sequence (0, 1, 2, 3), and therefore, an entry 324 identified by the stream sequence (0, 1, 2, 3) is added to the graph 132. As shown, the entry 324 includes a node of stream ID 0 332, a node of stream ID 1 334, a node of stream ID 2 336, and a node of stream ID 3 338. The node sequence matches the stream sequence (0, 1, 2, 3). Additionally, the entry 324 identified by the stream sequence (0, 1, 2, 3) includes a weight 340. The weight 340 is a value representing the number of times the same stream sequence is seen by the graph generation module 114. Therefore, after reading out the first stack 304, the weight 340 value is set to one, but each time the same stream sequence (0, 1, 2, 3) is read out, the value is increased.

[0051] For each stack that is sequentially read from the stack file 302 after the first stack 304, the graph generation module 114 is configured to determine whether the flow sequence in the stack currently being read sequentially (i.e., the "current" or "remaining" stack) matches the flow sequence in the previous stack that has been read sequentially. In other words, the graph generation module 114 is configured to determine whether the flow sequence of the current stack matches the flow sequence of an entry that already exists in the graph 132. If the flow sequence in the current stack matches the flow sequence in the previous stack, the graph generation module 114 increases the weight value of the corresponding entry. If the flow sequence in the current stack does not match the flow sequence in any previous stack, the graph generation module 114 adds the new entry to the graph 132.

[0052] Back to Figure 3A In the example of , the graph generation module 114 reads the second stack 306 from the stack file 302 and determines that the flow sequence (4, 2, 3) of the second stack 306 does not match the only existing entry 324 representing the flow sequence (0, 1, 2, 3). Therefore, the entry 326 identified by the flow sequence (4, 2, 3) is added to the graph 132 and its corresponding weight 342 value is set to one.

[0053] Next, the graph generation module 114 reads the third stack 308 from the stack file 302 and determines that the flow sequence (5, 6, 3) of the third stack 308 matches neither the flow sequence of the existing entry 324 nor the flow sequence of the existing entry 326. Therefore, the entry 328 identified by the flow sequence (5, 6, 3) is added to the graph 132 and its corresponding weight 344 value is set to one.

[0054] Next, the graph generation module 114 reads the fourth stack 310 from the stack file 302 and determines that the flow sequence (0, 1, 2, 3) of the fourth stack 310 matches the flow sequence of the existing entry 324. Therefore, the weight 340 of the entry 324 is increased from one to two.

[0055] Next, the graph generation module 114 reads the fifth stack 312 from the stack file 302 and determines that the flow sequence (7, 8, 6, 3) of the fifth stack 312 matches neither the flow sequence of the existing entry 324, the flow sequence of the existing entry 326, nor the flow sequence of the existing entry 328. Therefore, the entry 330 identified by the flow sequence (7, 8, 6, 3) is added to the graph 132, and its corresponding weight 346 value is set to one.

[0056] Next, the graph generation module 114 reads the sixth stack 314 from the stack file 302 and determines that the flow sequence (0, 1, 2, 3) of the sixth stack 314 matches the flow sequence of the existing entry 324. Therefore, the weight 340 of the entry 324 is increased from two to three.

[0057] Next, the graph generation module 114 reads the seventh stack 316 from the stack file 302 and determines that the flow sequence (4, 2, 3) of the seventh stack 316 matches the flow sequence of the existing entry 326. Therefore, the weight 342 of the entry 326 is increased from one to two.

[0058] Next, the graph generation module 114 reads the eighth stack 318 from the stack file 302 and determines that the flow sequence (0, 1, 2, 3) of the eighth stack 318 matches the flow sequence of the existing entry 324. Therefore, the weight 340 of the entry 324 increases from three to four - as shown. Figure 3A The final value for this example.

[0059] Next, the graph generation module 114 reads the ninth stack 320 from the stack file 302 and determines that the flow sequence (4, 2, 3) of the ninth stack 320 matches the flow sequence of the existing entry 326. Therefore, the weight 342 of the entry 326 is increased from two to three - as shown. Figure 3A The final value for this example.

[0060] Finally, the graph generation module 114 reads the tenth stack 322 from the stack file 302 and determines that the flow sequence (5, 6, 3) of the tenth stack 322 matches the flow sequence of the existing entry 328. Therefore, the weight 344 of the entry 328 is increased from one to two - as shown. Figure 3A The final value for this example.

[0061] Now, all stacks from the stack file 302 have been sequentially read, and FIG. 132 shows that the first entry 324 represents the first read stack, the fourth read stack, the sixth read stack, and the eighth read stack 348, so the value of the weight 340 is four. In addition, FIG. 132 shows that the second entry 326 represents the second read stack, the seventh read stack, and the ninth read stack 350, so the value of the weight 342 is three. FIG. 132 shows that the third entry 328 represents the third read stack and the tenth read stack 352, so the value of the weight 344 is two. And FIG. 132 shows that the fourth entry 330 represents the fifth read stack 354, so the value of the weight 346 is one.

[0062] Please note, Figure 3A The number of stacks used in (i.e., ten) is small and is used for ease of discussion. The stack file may have more stacks, and therefore, the graph generated for the stack file may have more entries and larger weight values. When the graph generation module 114 stores the graph 132 for analysis (e.g., writes the graph 132 to disk), the entries 324, 326, 328, 330 in the graph 132 are sorted according to decreasing weight values, such as Figure 3A This ensures that entries that are seen more often in the stack of stack files (e.g., entries with higher weight values ​​or hit counts) and are generally more important or meaningful from an analytical perspective are shown first when the graph 132 is read from disk. For example, a clear depiction of the performance of the cluster is apparent even when a small percentage of the data in the graph has been read.

[0063] The graph generation module 114 may additionally be configured to use pointers from a flow identifier (eg, flow node) in one entry of the graph to the same flow identifier in a different entry of the graph. Figure 3BAs shown in FIG. 1 , in response to determining that the flow sequence (4, 2, 3) of the second stack 306 read does not match the flow sequence (0, 1, 2, 3) of the first stack 304 that has been read, the graph generation module 114 searches for a flow identifier in entry 324 that matches the flow identifier in the new entry 326 added to the graph. Since there is no match for flow ID 4, a node 356 is added to entry 326. However, the subsequent sequence of flow IDs 2 and 3 is the same in entry 324. Therefore, in order to further save space when representing the stack in the graph, the graph generation module 114 adds a pointer 358 from the node 356 representing flow ID 4 to the node 336 representing flow ID 2 in entry 324. The flow sequence (4, 2, 3) remains intact via pointer 358.

[0064] Similarly, in response to determining that the flow sequence (5, 6, 3) of the third stack 308 matches neither the flow sequence (0, 1, 2, 3) of the first stack 304 nor the flow sequence (4, 2, 3) of the second stack 306, the graph generation module 114 searches for a flow identifier in entries 324 and 326 that matches the flow identifier in the new entry 328 added to the graph. Since flow ID 5 and flow ID 6 do not match, nodes 360 and 362 are added to entry 328. However, the subsequent flow ID 3 has a match in entry 324. Therefore, in order to further save space when representing the stack in the graph, the graph generation module 114 adds a pointer 364 from node 362 representing flow ID 6 to node 338 representing flow ID 3 in entry 324. The flow sequence (5, 6, 3) remains intact via pointer 364.

[0065] In another example, in response to determining that the flow sequence (7, 8, 6, 3) of the fifth stack 312 does not match the flow sequence that has been read, the graph generation module 114 searches for a flow identifier in entries 324, 326, and 328 that matches the flow identifier in the new entry 330 added to the graph. Since flow ID 7 and flow ID 8 do not match, nodes 366 and 368 are added to entry 330. However, the subsequent flow ID 6 has a match in entry 328 that represents the same flow - flow ID 6. Therefore, in order to further save space when representing the stack in the graph, the graph generation module 114 adds a pointer 370 from the node 368 representing flow ID 8 to the node 362 representing flow ID 6 in entry 328. Therefore, the flow sequence (7, 8, 6, 3) remains intact via pointer 370 and pointer 364.

[0066] Figure 4 An example diagram of pruning a graph representing a stack having entries, entry weight values, and / or pointers is shown. Figure 4 The figure is based on Figure 3B, except that the graph is now pruned graph 402. Graph pruning module 116 uses weight value threshold 134 to prune graph 132. Figure 4 In the example of , the weight value threshold is equal to three 404. The weight value threshold 134 can be established based on various factors such as the number of stacks, the number of entries, etc. In addition, the weight value threshold 134 can learn and adjust over time to adapt to different analysis scenarios.

[0067] exist Figure 4 , graph pruning module 116 determines that entries 324 and 326 have weight values ​​340 and 342 that satisfy weight value threshold 404 of three (e.g., weight value 340 of four and weight value 342 of three are greater than or equal to weight value threshold 404 of three). In contrast, graph pruning module 116 determines that weight values ​​344 and 346 of entries 328 and 330 fail to satisfy weight value threshold 404 of three (e.g., weight value 344 of two and weight value 346 of one are less than weight value threshold 404 of three). Therefore, entries 328 and 330 are not shown in FIG. Figure 4 In other words, entries 328 and 330 406 are removed from the graph. Thus, stacks 308, 312, and 322 are no longer represented in pruned graph 402, as shown by Figure 4 These stacks are indicated by an "X" in the stack file 302.

[0068] As described above, such pruning and / or removal may further improve efficiency with respect to sending, storing, and / or processing stack data in the graph, since the removed entries may be insignificant and / or meaningless from an analytical perspective.

[0069] An additional benefit of using entry weights is that graphs (eg, pruned graphs) can be efficiently merged with each other. Figure 5A An example graph is shown that is intended to merge 502 two graphs 504, 506. For example, the first graph 504 may be generated based on the stack file 124(1), and the second graph 506 may be generated based on the stack file 124(2). Figure 5A In the first graph 504, the first graph 504 includes Figure 4 4, and the second graph 506 includes another pruning graph 508. As shown, pruning graph 402 and pruning graph 508 include common entries 324 and 326, which include the same unique flow, and therefore, include the same nodes 332, 334, 336, 338, 356 and the same pointer 358. Note that pruning graph 402 may include entries not included in pruning graph 402, and vice versa, but this is not shown.

[0070] The difference between pruning graph 402 and pruning graph 508 is the weight value. Pruning graph 402 includes weight value 340 of four for entry 324, while pruning graph 508 includes weight value 510 of six for entry 324. In addition, pruning graph 402 includes weight value 342 of three for entry 326, while pruning graph 508 includes weight value 512 of four for entry 326.

[0071] The graph merging module 118 is configured to merge weight values ​​of common or matching entries from multiple graphs. Figure 5B As shown in , merge graph 514 includes a combined weight value 516 of ten for entry 324 and a combined weight value 518 of seven for entry 326 .

[0072] Merge (an example of which is in FIG. 5A to FIG. 5B ) can occur recursively as more stack data is collected (e.g., more stack files 124(1-N) are received), and due to this recursive merging, one graph can represent a large number of stack files and / or stacks. Ultimately, this alleviates the need to maintain a database to store a large number of stacks and / or stack files. Instead, analysis of stacks can be expanded through the use of graphs, graph pruning, and / or graph merging. For example, a graph of stacks collected from a cluster of client machines can be placed in a client-allocated storage account due to space reduction and removal of constraints.

[0073] Graphs can be merged together according to various timelines, which enables the inclusion of stack arrangements. For example, a graph can merge every twenty-four hour time window for each service in the fleet. In addition, as merging increases (e.g., more stack files and / or stacks are represented in a single graph), the weight value threshold for pruning the graph can increase.

[0074] Figure 6 An example graph is shown in which playback data is associated with each node in the graph. Figure 6 Shown from Figure 4 A pruned graph of , wherein each node 332 , 334 , 336 , 338 , and 356 includes playback data 602 .

[0075] Replay data 602 includes a timestamp associated with the execution of the stream, and attributes associated with the execution of the stream. Example attributes include process identification (PID) and / or thread identification (TID). Timestamps and attributes can be used to replay the execution of the stream at a specific machine. In various examples, playback data 602 is stored and read from different locations in the figure. Each playback data entry points to a node in the figure.

[0076] For example, each time flow ID0 332 is executed (e.g., at least four times in this example), timestamp 604 and attribute 606 are registered. Similarly, each time flow ID 1 334 is executed (e.g., at least four times in this example), timestamp 608 and attribute 610 are registered. Each time flow ID 2 336 is executed (e.g., at least seven times in this example), timestamp 612 and attribute 614 are registered. Each time flow ID 3 338 is executed (e.g., at least seven times in this example), timestamp 616 and attribute 618 are registered. And, each time flow ID 4 356 is executed (e.g., at least three times in this example), timestamp 620 and attribute 622 are registered.

[0077] Now go to Figure 7 , describes aspects of a method 700 implemented by a machine. At operation 702, the machine accesses a stack to be sent to a stack analysis service. At operation 704, the machine represents a first stream of the stack using an actual address. At operation 706, the machine represents each stream of the stack after the first stream using an address offset. At operation 708, the machine variable-bit encodes the stack for transmission.

[0078] Figure 8 is an example flow chart illustrating aspects of a method 800 implemented by a stack analysis service to generate a graph representing stacks in a stack file. At operation 802, the stack analysis service receives a stack file containing stacks. At operation 804, the stack analysis service calculates flow (e.g., node) identities (e.g., addresses) for flows in each stack using a baseline address and (multiple) address offsets. At operation 806, the stack analysis service adds an entry to the graph for the first stack sequentially read from the stack file.

[0079] At operation 808, the stack analysis service determines whether the remaining stack (e.g., the current stack being read) matches the previous stack. If the determination at operation 808 is yes (i.e., the remaining stack matches the previous stack, and therefore, an entry for the remaining stack already exists in the graph), the corresponding weight value of the entry associated with the remaining stack and the previous stack is increased at operation 810. The process then returns to operation 808 to read the next stack. If the determination at operation 808 is no (i.e., the remaining stack does not match any previous stack, and therefore, an entry for the remaining stack does not yet exist in the graph), the new entry is added to the graph at operation 812. The process then returns to operation 808 to read the next stack. When there are no more stacks in the stack file to be evaluated with respect to operation 808 (as captured at 814), the stack analysis service continues to prune the graph using the weight value threshold at operation 816.

[0080] For ease of understanding, the processes discussed in this disclosure are depicted as separate operations represented as independent blocks. However, these separately depicted operations should not be interpreted as necessarily relying on order in their execution. The order in which the processes are described is not intended to be interpreted as limiting, and any number of the described process blocks may be combined in any order to implement the process or an alternative process. In addition, one or more of the provided operations may also be modified or omitted.

[0081] The specific implementation of the technology disclosed herein depends on the performance and other requirements of the computing device. Therefore, the logical operation described herein can be referred to as state, operation, structural device, action or module in various ways. These states, operations, structural devices, actions and modules can be implemented in hardware, software, firmware, in dedicated digital logic, and in any combination thereof. It should be appreciated that more or less operations than those shown in the figure and described herein can be performed. These operations can also be performed in an order different from the order described herein.

[0082] It should also be understood that the method shown can be terminated at any time and does not need to be performed in full. Some or all of the operations of the method and / or substantially equivalent operations can be performed by executing computer-readable instructions contained on a computer storage medium, as defined below. The term "computer-readable instructions" and its variants as used in the specification and claims are used broadly herein to include routines, applications, application modules, program modules, programs, components, data structures, algorithms, etc. Computer-readable instructions can be implemented on various system configurations, including single-processor or multi-processor systems, minicomputers, mainframe computers, personal computers, handheld computing devices, microprocessor-based programmable consumer electronics, combinations thereof, and the like.

[0083] Therefore, it should be recognized that the logical operations described herein are implemented as (1) a sequence of computer-implemented actions or program modules running on a computing system and / or (2) interconnected machine logic circuits or circuit modules within a computing system. The implementation method depends on the performance and other requirements of the computing system.

[0084] Fig. 9 Additional details of an example computer architecture 900 are shown for a device such as a computer or server capable of executing computer instructions (eg, components described herein). Fig. 9The computer architecture 900 shown in includes (multiple) processing units 902, system memory 904 (including random access memory 906 (RAM) and read-only memory (ROM) 908), and a system bus 910 that couples the memory 904 to the (multiple) processing units 902. The processing unit 902 may also include or be part of a processing system. In various examples, the processing units 902 of the processing system are distributed. In other words, one processing unit 902 of the processing system may be located in a first location (e.g., a rack within a data center), while another processing unit 902 of the processing system is located in a second location separate from the first location.

[0085] Processing unit(s) such as processing unit(s) 902 may represent, for example, a CPU-type processing unit, a GPU-type processing unit, a field programmable gate array (FPGA), another type of digital signal processor (DSP), or other hardware logic components that may be driven by a CPU in some cases. For example, illustrative types of hardware logic components that may be used include application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), etc.

[0086] Stored in ROM 908 is a basic input / output system containing the basic routines that help transfer information between elements within the computer architecture 900 (such as during startup). The computer architecture 900 also includes a mass storage device 912 for storing an operating system 914, application(s) 916, modules 918, and other data described herein.

[0087] The mass storage device 912 is connected to the processing unit(s) 902 through a mass storage controller connected to the bus 910. The mass storage device 912 and its associated computer readable media provide non-volatile storage for the computer architecture 900. Although the descriptions of computer readable media contained herein refer to mass storage devices, those skilled in the art will recognize that computer readable media may be any available computer readable storage media or communication media that can be accessed by the computer architecture 900.

[0088] Computer-readable media include computer-readable storage media and / or communication media. Computer-readable storage media include one or more of volatile memory, non-volatile memory and / or other persistent and / or auxiliary computer storage media, removable and non-removable computer storage media, implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. Therefore, computer storage media include media in tangible and / or physical form contained in a device and / or a hardware component that is part of the device or external to the device, including RAM, static RAM (SRAM), dynamic RAM (DRAM), phase change memory (PCM), ROM, erasable programmable ROM (EPROM), electrical EPROM (EEPROM), flash memory, compact disk read-only memory (CD-ROM), digital versatile disk (DVD), optical card or other optical storage medium, magnetic cassette, magnetic tape, magnetic disk storage, magnetic card or other magnetic storage device or medium, solid-state memory device, storage array, network attached storage, storage area network, hosted computer storage or any other storage memory, storage device and / or storage medium that can be used to store and maintain information for access by a computing device.

[0089] In contrast to computer-readable storage media, communication media may embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal (such as a carrier wave or other transmission mechanism). As defined herein, computer storage media does not include communication media. That is, computer-readable storage media does not include communication media that consists solely of a modulated data signal, a carrier wave, or a propagation signal itself.

[0090] According to various configurations, the computer architecture 900 can operate in a network environment using logical connections to remote computers through the network 920. The computer architecture 900 can be connected to the network 920 through a network interface unit 922 connected to the bus 910.

[0091] It should be appreciated that the software components described herein can transform (multiple) processing units 902 and the overall computer architecture 900 from a general-purpose computing system into a special-purpose computing system customized to facilitate the functions presented herein when loaded into (multiple) processing units 902 and executed. (Multiple) processing units 902 can be composed of any number of transistors or other discrete circuit elements, which can present any number of states individually or collectively. More specifically, (multiple) processing units 902 can be operated as finite state machines to respond to executable instructions contained in the software modules described herein. These computer executable instructions can transform (multiple) processing units 902 by specifying how (multiple) processing units 902 transition between states, thereby transforming the transistors or other discrete hardware elements that constitute (multiple) processing units 902.

[0092] The disclosure presented herein also covers the subject matter set forth in the following clauses.

[0093] Example clause A, a method, comprising: receiving a stack file comprising a plurality of stacks, wherein each stack of the plurality of stacks comprises a flow sequence; generating a graph for the stack file by sequentially reading the plurality of stacks from the stack file, the graph comprising a plurality of entries, and each entry of the plurality of entries represents a unique flow sequence, wherein generating the graph comprises: adding a first entry to the graph, the first entry representing the flow sequence in a first stack of the plurality of stacks; for the remaining stacks of the plurality of stacks after the first stack: determining that a specific flow sequence contained in the remaining stacks of the plurality of stacks matches a previous flow sequence contained in a previous stack of the plurality of stacks; and based on determining that the specific flow sequence contained in the remaining stacks matches the previous flow sequence contained in the previous stack, for the corresponding entries contained in the graph, increasing a corresponding weight value representing the number of times the previous flow sequence appears in the plurality of stacks; determining that the weight value of a specific entry of the plurality of entries fails to meet a weight value threshold; and based on determining that the weight value of the specific entry fails to meet the weight value threshold, removing the specific entry from the graph.

[0094] Example clause B, a method according to example clause A, wherein removing the particular entry from the graph produces a pruned graph, the method further comprising writing the remaining entries of the pruned graph to a memory in order of decreasing weight value.

[0095] Example Clause C. The method according to Example Clause A or Example Clause B, further comprising merging the graph with another graph by combining the weight values ​​for matching entries.

[0096] Example clause D, a method according to any one of example clauses A to C, wherein: each of the multiple stacks is received in a format that uses an address to represent a first stream in the stream sequence, and each stream in the stream sequence after the first stream uses an address offset from a previous stream in the stream sequence; and the method further includes: recalculating the address of each stream in the stream sequence using the address representing the first stream and at least one address offset representing each stream after the first stream; and using the address of each stream as a stream identifier in the graph.

[0097] Example clause E, a method according to example clause D, wherein a format variable bit encodes the address and the address offset.

[0098] Example clause F, a method according to any one of example clauses A to E, wherein the graph includes playback data, the playback data including a timestamp of each time the flow is executed and identifying a thread identifier or a process identifier associated with each time the flow is executed.

[0099] Example clause G, a method, comprising: receiving a stack file comprising a plurality of stacks, wherein each stack of the plurality of stacks comprises a flow sequence; generating a graph for the stack file by sequentially reading the plurality of stacks from the stack file, the graph comprising a plurality of entries, and each entry of the plurality of entries represents a unique flow sequence, wherein generating the graph comprises: adding a first entry to the graph, the first entry representing the flow sequence in a first stack of the plurality of stacks; for the remaining stacks of the plurality of stacks after the first stack: determining that a particular flow sequence contained in the remaining stacks of the plurality of stacks does not match a previous flow sequence contained in a previous stack of the plurality of stacks; and based on determining that the particular flow sequence contained in the remaining stacks does not match the previous flow sequence contained in the previous stack, adding a new entry to the graph; determining that a weight value for a particular entry of the plurality of entries contained in the graph fails to satisfy a weight value threshold; and based on determining that the weight value for the particular entry fails to satisfy the weight value threshold, removing the particular entry from the graph.

[0100] Example clause H, a method according to example clause G, wherein removing the particular entry from the graph produces a pruned graph, the method further comprising writing the remaining entries of the pruned graph to a memory in order of decreasing weight value.

[0101] Example Clause I. The method according to Example Clause G or Example Clause H, further comprising merging the graph with another graph by combining the weight values ​​for matching entries.

[0102] Example clause J, a method according to any one of example clauses G to I, wherein: each of the multiple stacks is received in a format that uses an address to represent a first stream in the stream sequence, and each stream in the stream sequence after the first stream uses an address offset from a previous stream in the stream sequence; and the method further includes: recalculating an address for each stream in the stream sequence using an address representing the first stream and at least one address offset representing each stream after the first stream; and using the address for each stream as a stream identifier in the graph.

[0103] Example clause K, a method according to example clause J, wherein a format variable bit encodes the address and the address offset.

[0104] Example clause L, the method according to any one of example clauses G to K, further includes: based on determining that the specific flow sequence contained in the remaining stack does not match the previous flow sequence contained in the previous stack, determining that the remaining flow identifier contained in the remaining stack matches the previous flow identifier contained in the previous stack; and adding a pointer from a new entry to an existing entry containing the previous flow identifier.

[0105] Example clause M, a method according to any one of example clauses G to L, wherein the graph includes playback data, the playback data including a timestamp of each time the flow is executed and identifying a thread identifier or a process identifier associated with each time the flow is executed.

[0106] Example clause N, a system comprising: a processing system; and a computer-readable storage medium storing instructions which, when executed by the processing system, cause the system to: generate a graph for a stack file comprising a plurality of stacks by sequentially reading the plurality of stacks from the stack file, wherein: each stack of the plurality of stacks comprises a flow sequence; the graph comprises a plurality of entries; and each entry of the plurality of entries represents a unique flow sequence and comprises a weight value representing the number of times the unique flow sequence appears in the stack file; determine that a weight value for an entry of the plurality of entries fails to satisfy a weight value threshold; and remove the entry from the graph based on determining that the weight value for the entry fails to satisfy the weight value threshold.

[0107] Example clause O, a system according to example clause N, wherein removing entries from the graph produces a pruned graph, and the instructions further cause the system to write the remaining entries of the pruned graph to a memory in order of decreasing weight value.

[0108] Example clause P, a system according to example clause N or example clause O, wherein the instructions further cause the system to merge the graph with another graph by reading and combining the weight values ​​of the entries.

[0109] Example clause Q, a system according to any one of example clauses N to P, wherein: each of the multiple stacks is received in a format that uses an address to represent a first stream in the stream sequence, and each stream in the stream sequence after the first stream uses an address offset from a previous stream in the stream sequence; and the instruction also causes the system to: recalculate the address of each stream in the stream sequence using an address representing the first stream and at least one address offset representing each stream after the first stream; and use the address of each stream as a stream identifier in the graph.

[0110] Example clause R, a system according to example clause Q, wherein the format variable bits encode the address and the address offset.

[0111] Example clause S, a system according to any one of example clauses N to R, wherein the graph includes playback data, the playback data including a timestamp of each time the flow is executed and identifying a thread identifier or a process identifier associated with each time the flow is executed.

[0112] Example clause T. The system of any of example clauses N to S, wherein the instructions further cause the system to receive the stack file from a machine.

[0113] Although certain example embodiments have been described, these embodiments have been presented by way of example only and are not intended to limit the scope of the inventions disclosed herein. Therefore, nothing in the foregoing description is intended to imply that any particular feature, characteristic, step, component, module, or block is necessary or indispensable. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions, and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions disclosed herein. The accompanying claims and their equivalents are intended to cover such forms or modifications that fall within the scope and spirit of certain inventions disclosed herein.

[0114] It should be appreciated that any reference to a "first", "second", etc. element in the Summary of the Invention and / or Detailed Description is not intended to and should not be interpreted as necessarily corresponding to any reference to a "first", "second", etc. element in the claims. On the contrary, any use of "first" and "second" in the Summary of the Invention, Detailed Description, and / or Claims can be used to distinguish two different instances of the same element (e.g., two different stacks).

[0115] Finally, although various configurations have been described using language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the accompanying representations is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed subject matter.

Claims

1. A method comprising: receiving a stack file comprising a plurality of stacks, wherein each stack of the plurality of stacks comprises a sequence of streams; Generating a graph for the stack file by sequentially reading the plurality of stacks from the stack file, the graph comprising a plurality of entries, and each entry in the plurality of entries represents a unique stream sequence, wherein generating the graph comprises: adding a first entry to the graph, the first entry representing the sequence of flows in a first stack of the plurality of stacks; For remaining stacks of the plurality of stacks after the first stack: determining that a particular sequence of flows contained in the remaining stacks of the plurality of stacks matches a previous sequence of flows contained in a previous stack of the plurality of stacks; and Based on determining that the particular flow sequence included in the remaining stack matches the previous flow sequence included in the previous stack, increasing, for a corresponding entry included in the graph, a corresponding weight value representing a number of times the previous flow sequence appears in the plurality of stacks; determining that a weight value for a particular entry in the plurality of entries fails to satisfy a weight value threshold; and Based on determining that the weight value for the particular entry fails to satisfy the weight value threshold, the particular entry is removed from the graph.

2. The method of claim 1, wherein removing the particular entry from the graph produces a pruned graph, the method further comprising writing remaining entries of the pruned graph to a memory in order of decreasing weight value.

3. The method of claim 1 or claim 2, further comprising merging the graph with another graph by combining the weight values ​​for matching entries.

4. The method according to any one of claims 1 to 3, wherein: each stack of the plurality of stacks is received in a format that uses an address to represent a first stream in the sequence of streams, and each stream in the sequence of streams subsequent to the first stream uses an address offset from a previous stream in the sequence of streams; and The method further comprises: recalculating an address for each stream in the sequence of streams using the address representing the first stream and at least one address offset representing each stream subsequent to the first stream; as well as The address for each flow is used as the flow identification in the graph. The method of claim 4 , wherein a format variable bit encodes the address and the address offset.

6. The method according to any one of claims 1 to 5, wherein the graph includes playback data, the playback data including a timestamp of each time a flow is executed and identifying a thread ID or a process ID associated with each time the flow is executed.

7. A method comprising: receiving a stack file comprising a plurality of stacks, wherein each stack of the plurality of stacks comprises a sequence of streams; Generating a graph for the stack file by sequentially reading the plurality of stacks from the stack file, the graph comprising a plurality of entries, and each entry in the plurality of entries represents a unique stream sequence, wherein generating the graph comprises: adding a first entry to the graph, the first entry representing the sequence of flows in a first stack of the plurality of stacks; For remaining stacks of the plurality of stacks after the first stack: determining that a particular sequence of flows contained in the remaining stacks in the plurality of stacks does not match a previous sequence of flows contained in a previous stack in the plurality of stacks; and adding a new entry to the graph based on determining that the particular flow sequence contained in the remaining stack does not match the previous flow sequence contained in the previous stack; determining that a weight value for a particular entry among the plurality of entries included in the graph fails to satisfy a weight value threshold; and Based on determining that the weight value for the particular entry fails to satisfy the weight value threshold, the particular entry is removed from the graph.

8. The method of claim 7, wherein removing the particular entry from the graph produces a pruned graph, the method further comprising writing remaining entries of the pruned graph to a memory in order of decreasing weight value.

9. The method of claim 7 or claim 8, further comprising merging the graph with another graph by combining the weight values ​​for matching entries.

10. The method according to any one of claims 7 to 9, wherein: each stack of the plurality of stacks is received in a format that uses an address to represent a first stream in the sequence of streams, and each stream in the sequence of streams subsequent to the first stream uses an address offset from a previous stream in the sequence of streams; and The method further comprises: recalculating an address for each stream in the sequence of streams using the address representing the first stream and at least one address offset representing each stream subsequent to the first stream; as well as The address for each flow is used as the flow identification in the graph. The method of claim 10 , wherein a format variable bit encodes the address and the address offset.

12. The method according to any one of claims 7 to 11, further comprising: Based on determining that the specific flow sequence included in the remaining stack does not match the previous flow sequence included in the previous stack, determining that the remaining flow identifiers included in the remaining stack match the previous flow identifiers included in the previous stack; and A pointer is added from the new entry to the existing entry containing the previous stream identification.

13. The method according to any one of claims 7 to 12, wherein the graph includes playback data, the playback data including a timestamp of each time a flow is executed and identifying a thread identification or a process identification associated with each time the flow is executed.

14. A system comprising: Processing systems; as well as A computer-readable storage medium storing instructions that, when executed by the processing system, cause the system to: A graph is generated for a stack file by sequentially reading the plurality of stacks from the stack file, wherein: Each stack of the plurality of stacks comprises a sequence of flows; The graph includes a plurality of entries; and Each entry in the plurality of entries represents a unique flow sequence and includes a weight value representing a number of times the unique flow sequence appears in the stack file; determining that a weight value for an entry in the plurality of entries fails to satisfy a weight value threshold; and Based on determining that the weight value for the entry fails to satisfy the weight value threshold, the entry is removed from the graph.

15. The system of claim 14, wherein removing the entries from the graph produces a pruned graph, and the instructions further cause the system to write remaining entries of the pruned graph to memory in order of decreasing weight value.

Images