Dynamic Method Instrumentation for Runtime Performance Diagnosis
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing software monitoring techniques face challenges in deciding which components to instrument, leading to excessive overhead or omission of important performance data, making analysis and diagnosis difficult.
Innovation Solution
A computer-implemented method that dynamically identifies and instruments un-instrumented components during runtime by discovering callable methods through byte code inspection, allowing for selective and efficient data collection without initial over-inclusive instrumentation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If over-inclusive instrumentation is applied to monitor all software components, then measurement precision is improved, but device complexity and overhead increase
Solution Approach 1:
The system dynamically determines which components to instrument based on runtime performance data and diagnostic needs. Instead of static over-inclusive instrumentation, the system adapts its instrumentation scope by identifying components that actually need monitoring based on observed performance issues, thereby reducing overhead while maintaining measurement precision when needed.
Solution Approach 2:
The system extracts and focuses instrumentation only on specific components that are identified as problematic through performance data analysis. By taking out instrumentation from the broad set of all components and applying it selectively to only those components that need monitoring, the system reduces overall instrumentation overhead while maintaining precise measurement of critical areas.
2Device complexity
If under-inclusive instrumentation is applied to reduce overhead, then device complexity is reduced, but measurement precision deteriorates due to omission of important performance data
Solution Approach 1:
The system uses performance data feedback to continuously improve its instrumentation strategy. By monitoring performance metrics and using this feedback to identify components that need instrumentation, the system dynamically adjusts its monitoring scope to ensure important performance data is captured without maintaining excessive instrumentation overhead.
Solution Approach 2:
The system performs preliminary analysis of performance data to identify components that are likely to be problematic before applying instrumentation. This preliminary action allows the system to proactively instrument only the components that need monitoring, rather than reacting after issues occur, thereby maintaining measurement precision while minimizing overhead.
3Device complexity
If selective instrumentation is applied to reduce overhead, then device complexity is reduced, but difficulty of detecting and measuring increases due to omission of important performance data
Solution Approach 1:
The system performs self-diagnosis by analyzing performance data to automatically identify which components need instrumentation. This self-service capability allows the system to make intelligent decisions about instrumentation scope without external intervention, reducing the difficulty of detection and measurement by using its own performance data to guide its monitoring strategy.
Solution Approach 2:
The system changes its instrumentation parameters dynamically based on performance data analysis. By adjusting which components are instrumented based on observed performance characteristics, the system optimizes the balance between overhead and diagnostic capability, making it easier to detect and measure performance issues in critical areas.
Data Source
Figure 1~2
Figure 3
Figure 4A~4B
AI summary
A technique for analyzing software in which un-instrumented components can be discovered and dynamically instrumented during a runtime of the software. Initially, an application configured with a baseline set of instrumented components such as methods. As the application runs, performance data is gathered from the instrumentation, and it may be learned that the performance of some methods is an issue. To analyze the problem, any methods which are callable from a method at issue are discovered by inspecting the byte code of loaded classes in a JAVA Virtual Machine (JVM). Byte code of the class is parsed to identify opcodes which invoke byte code to call other methods. An index to an entry in a constants pool table is identified based on an opcode. A decision can then be made to instrument and/or report the discovered methods.