Abstract: A computer-implemented method of controlling power consumption in a multi-processor computing device comprises: determining whether a first processor is operating in a high-power regime or a low-power regime; selecting a first set of control rules that includes a first subset of control rules that apply when the first processor is operating in the high-power regime and a second subset of control rules that apply when the first processor is operating in the low-power regime; determining one or more power settings for the first processor based on the first set of control rules; and causing the first processor to perform one or more operations based on the one or more power settings.

Abstract: Embodiments improve software defect diagnosis. Analytic focus is automatically walked back from an initial symptomatic diagnostic context to a previous diagnostic context that is closer to underlying causes. Diagnosis may obtain diagnostic artifacts such as traces or dumps, extract diagnostic context, decompile executables, lookup likely causes based on symptoms, scan logs, and submit diagnostic context to software analysis services. An analysis service may perform static analysis, security testing, symptom-pair lookups, or antipattern scanning, for example, and may include a neural network or other machine learning model, for example. Root causes are culled from analysis results and identified to a software developer. Changes to mitigate the defect's impact are suggested in some cases. Thus, the software developer receives debugging leads without manually navigating through all the tool interfaces or unrelated details of diagnostic contexts.

Abstract: A computer-implemented method and computer program for executing vehicle data sharing between vehicles. The method includes the steps of transmitting location data to a first network identifying a location of a first vehicle on a roadway; receiving data from the first network indicating that a second vehicle is within a predetermined proximity of the first vehicle; and transmitting data from the first vehicle to the second vehicle via a second network. The first network may be a cellular network, and the second network may be a Wi-Fi network. Also described is a method for executing a cryptocurrency transaction between the vehicles including the steps of receiving, and then comparing, respective vehicle performance related data from the first and second vehicles; and debiting a wallet of one of the two vehicles and crediting the wallet of the other vehicle of the vehicles as a function of the comparison.

Abstract: Automatic identification of execution behavior(s) of software. This automatic identification is based on analysis of historical execution records using machine learning to identify a particular pattern that corresponds to an execution behavior. In order to automatically identify an execution behavior present within particular software, an execution record of that particular software is accessed. The execution record includes an execution trace that reproducibly represents the execution of the software within a particular execution environment, such that the execution record is usable to rerun the execution of the software precisely as the software previously run. Based on finding the particular pattern within the execution record, the computing system automatically identifies that the execution behavior is present within the software.

Abstract: Based on replay of a thread, one implementation observes an influx of a value of a memory cell comprising an interaction between the thread and the value of the memory cell at an execution time point in the replaying, and determines whether the value of the memory cell observed from the influx is inconsistent with a prior value of the memory cell as known by the thread at the execution time point. If so, this implementation initiates an indication of a data inconsistency. Based on replay of a plurality of threads, another implementation identifies a memory cell that was accessed by a first thread while a thread synchronization mechanism was active on the first thread. Then, if there was another access to the memory cell by a second thread without use of the thread synchronization mechanism, this implementation initiates an indication of a potential data contention.

Abstract: Expressly turning tracing on and off at each juncture between code that a developer wants to have traced and other code may reduce trace file size but adds computational cost. Described technologies support selectively tracing a process's execution, with some extra tracing done beyond the code the developer wanted traced, but with significantly reduced computational cost, by reducing the number of trace enablement and disablement operations. A trace controller uses a tracing disablement distance variable whose values indicate the computational distance from trace disablement. A distance variable modifier automatically moves the distance variable closer to a stop-tracing value as the process executes. The amount of extra tracing is balanced against the reduction in trace enablement/disablement operations by tuning thresholds, based on information about routine size and computational cost.

Abstract: Based on replay of a thread, one implementation observes an influx of a value of a memory cell comprising an interaction between the thread and the value of the memory cell at an execution time point in the replaying, and determines whether the value of the memory cell observed from the influx is inconsistent with a prior value of the memory cell as known by the thread at the execution time point. If so, this implementation initiates an indication of a data inconsistency. Based on replay of a plurality of threads, another implementation identifies a memory cell that was accessed by a first thread while a thread synchronization mechanism was active on the first thread. Then, if there was another access to the memory cell by a second thread without use of the thread synchronization mechanism, this implementation initiates an indication of a potential data contention.

Abstract: Identifying and reporting potential data inconsistencies and/or potential data contentions based on historic debugging traces. Based on replay of a thread, some implementations observe an influx of a value to a memory cell, and determine whether the value of the memory cell observed from the influx is inconsistent with a prior value of the memory cell as known by the thread. If so, these implementations can initiate an indication of a data inconsistency. Based on replay of a plurality of threads, other implementations identify a memory cell that was accessed by a first thread while a thread synchronization mechanism was active on the first thread. Then, if there was another access to the memory cell by a second thread without use of the thread synchronization mechanism, these implementations might initiate an indication of a potential data contention.

Abstract: Performing reverse execution debugging of an application. The method includes identifying a snapshot of application state for an application in an application framework. The method further includes emulating execution of the application, using bytecode, in a forward direction from the snapshot to an end point, causing generation of historical execution state at various points along the emulation of the application. The method further includes collecting the historical execution state. The method further includes using the collected historical execution state, emulating reverse execution of the application by substituting collected historical execution state, when needed, to restore previous state needed as a result of emulation of reverse execution of the application.

Abstract: Collecting runtime virtual machine external state for an application running in an application runtime virtual machine, for use in emulation of the application. A method includes identifying application bytecode for which runtime virtual machine external state is to be collected. The method further includes executing machine code generated from the bytecode to generate the runtime virtual machine external state. The method further includes collecting the runtime virtual machine external state. The method further includes storing the runtime virtual machine external state for use in emulating the application.

Abstract: Embodiments improve software defect diagnosis. Analytic focus is automatically walked back from an initial symptomatic diagnostic context to a previous diagnostic context that is closer to underlying causes. Diagnosis may obtain diagnostic artifacts such as traces or dumps, extract diagnostic context, decompile executables, lookup likely causes based on symptoms, scan logs, and submit diagnostic context to software analysis services. An analysis service may perform static analysis, security testing, symptom-pair lookups, or antipattern scanning, for example, and may include a neural network or other machine learning model, for example. Root causes are culled from analysis results and identified to a software developer. Changes to mitigate the defect's impact are suggested in some cases. Thus, the software developer receives debugging leads without manually navigating through all the tool interfaces or unrelated details of diagnostic contexts.

Abstract: Embodiments provide improved diagnosis of software defects. Static analysis services and other source-based diagnostic tools and techniques are applied even when the source code underlying software is unavailable. Diagnosis obtains diagnostic artifacts, extracts diagnostic context from the artifacts, decompiles to get source, and submits decompiled source to a source-based software analysis service. The analysis service may be a static analysis tool, an antipattern scanner, or a machine learning model trained on source code, for example. The diagnostic context may also guide the analysis, e.g., by localizing decompilation or prioritizing possible causes. Likely causes are culled from analysis results and identified to a software developer. Changes to mitigate the defect's impact are suggested. Thus, the software developer receives debugging leads without providing source code for the defective program, and without manually navigating through a decompiler and through the analysis services.

Abstract: Automatic identification of execution behavior(s) of software. This automatic identification is based on analysis of historical execution records using machine learning to identify a particular pattern that corresponds to an execution behavior. In order to automatically identify an execution behavior present within particular software, an execution record of that particular software is accessed. The execution record includes an execution trace that reproducibly represents the execution of the software within a particular execution environment, such that the execution record is usable to rerun the execution of the software precisely as the software previously run. Based on finding the particular pattern within the execution record, the computing system automatically identifies that the execution behavior is present within the software.

Abstract: Dynamically instrumenting code that executes based on a historic execution of a subject executable entity. Historic execution information for a subject executable entity is accessed. The historic execution information includes execution state information for at least one point in time in the historic execution the executable entity. Diagnostic code instruction(s) are identified, for instrumenting subject code instruction(s) of the executable entity. The subject code instruction(s) are virtually executed based at least on supplying the subject code instruction(s) with data from the historic execution information. While virtually executing the identified executable code instruction(s), the diagnostic code instruction(s) are also executed. The diagnostic code instruction(s) collecting diagnostic data regarding the virtual execution of the subject code instruction(s), or override at least one of a value or an execution behavior of the subject code instruction(s).

Abstract: The automatic identification of execution behavior(s) of software. This automatic identification is based on a historical analysis of execution records to identify a particular pattern that represents an execution behavior. In order to automatically identify an execution behavior present within particular software, an execution record (or perhaps multiple execution records) representing the execution of that particular software may be accessed. Based on finding the particular pattern within the execution record (or one, some, or all of the multiple execution records) representing the execution of that particular software, the computing system may automatically identify that the execution behavior is present within the software. This may dramatically assist in modifying that execution behavior.

Abstract: Techniques are provided to use historic execution state information to visualize tracepoint data. For example, historic execution state information corresponding to an application's previous execution is accessed. This historic execution state information was collected while the application was executing. After correlating the historic execution state information to the application's code, a tracepoint is associated with a portion of the code. Consequently, when the code is replayed based on the historic execution state information, the tracepoint causes a behavior of that code portion to be logged while the code is replayed uninterrupted. The code is then actually replayed based on the historic execution state information. During the replay, the tracepoint causes the behavior of the code portion to be logged. The logged behavior is visualized on a user interface.

Abstract: A mobile apparatus comprising a backpack having an inward body side and an outward non-body side, where the body side and the non-body side define an interior compartment. The backpack includes an active element coupled to an outer surface of the non-body side of the backpack, where the active element comprises a digital display. The backpack further includes a removable power supply housed in the interior compartment of the backpack, and a transmitter electrically coupled between the power supply and the active element. The transmitter is in wireless electrical communication with a remote central processing unit (CPU) for receiving and sending data files of content and images to be broadcast on the active element.

Abstract: Identifying and reporting potential data inconsistencies and/or potential data contentions based on historic debugging traces. Based on replay of a thread, some implementations observe an influx of a value to a memory cell, and determine whether the value of the memory cell observed from the influx is inconsistent with a prior value of the memory cell as known by the thread. If so, these implementations can initiate an indication of a data inconsistency. Based on replay of a plurality of threads, other implementations identify a memory cell that was accessed by a first thread while a thread synchronization mechanism was active on the first thread. Then, if there was another access to the memory cell by a second thread without use of the thread synchronization mechanism, these implementations might initiate an indication of a potential data contention.

Abstract: Expressly turning tracing on and off at each juncture between code that a developer wants to have traced and other code may reduce trace file size but adds computational cost. Described technologies support selectively tracing a process's execution, with some extra tracing done beyond the code the developer wanted traced, but with significantly reduced computational cost, by reducing the number of trace enablement and disablement operations. A trace controller uses a tracing disablement distance variable whose values indicate the computational distance from trace disablement. A distance variable modifier automatically moves the distance variable closer to a stop-tracing value as the process executes. The amount of extra tracing is balanced against the reduction in trace enablement/disablement operations by tuning thresholds, based on information about routine size and computational cost.

Abstract: Collecting runtime virtual machine external state for an application running in an application runtime virtual machine, for use in emulation of the application. A method includes identifying application bytecode for which runtime virtual machine external state is to be collected. The method further includes executing machine code generated from the bytecode to generate the runtime virtual machine external state. The method further includes collecting the runtime virtual machine external state. The method further includes storing the runtime virtual machine external state for use in emulating the application.