KR101705265B1 - 동적 인스트루먼테이션을 통한 커스텀 코드의 진단을 스트림라인하기위한 메소드 콜의 검출 - Google Patents

동적 인스트루먼테이션을 통한 커스텀 코드의 진단을 스트림라인하기위한 메소드 콜의 검출 Download PDF

Info

Publication number
KR101705265B1
KR101705265B1 KR1020110044254A KR20110044254A KR101705265B1 KR 101705265 B1 KR101705265 B1 KR 101705265B1 KR 1020110044254 A KR1020110044254 A KR 1020110044254A KR 20110044254 A KR20110044254 A KR 20110044254A KR 101705265 B1 KR101705265 B1 KR 101705265B1
Authority
KR
South Korea
Prior art keywords
reference method
application
class
methods
child
Prior art date
Application number
KR1020110044254A
Other languages
English (en)
Other versions
KR20110124733A (ko
Inventor
마르코 가글리아르디
Original Assignee
씨에이, 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 씨에이, 인크. filed Critical 씨에이, 인크.
Publication of KR20110124733A publication Critical patent/KR20110124733A/ko
Application granted granted Critical
Publication of KR101705265B1 publication Critical patent/KR101705265B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3612—Software analysis for verifying properties of programs by runtime analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44589—Program code verification, e.g. Java bytecode verification, proof-carrying code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3017—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is implementing multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3644—Software debugging by instrumenting at runtime
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/167—Interprocessor communication using a common memory, e.g. mailbox
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields

Abstract

소프트웨어의 런타임 동안 언인스트루먼트 컴포넌트들이 디스커버 및 인스트루먼트되는 소프트웨어를 분석하는 기법이 개시된다. 먼저, 어플리케이션이 메소드들과 같은 그러한 인스트루먼트 컴포넌트들의 베이스라인 세트로 구성된다. 이 어플리케이션이 실행될 때, 인스트루먼테이션으로부터 성능 데이터가 수집되고, 일부 메소드들의 수행이 문제가 있는지 학습하게 된다. 문제를 분석하기 위해, 문제의 메소드로부터 콜가능한 메소드들이 JAVA 가상 머신(JVM)으로 로드된 클래스들의 바이트 코드를 검사하는 것 등에 의해 디스커버된다. 이 클래스의 바이트 코드는 다른 메소드들을 콜하도록 바이트 코드를 인보크하는 오피코드들을 식별하기 위해 파싱된다. 상수 풀 테이블에 있는 엔트리에 대한 인덱스가 오피코드에 근거하여 식별된다. 이후, 디스커버된 메소드들을 인스트루먼트 및/또는 보고를 행할지 판단이 이루어진다.

Description

동적 인스트루먼테이션을 통한 커스텀 코드의 진단을 스트림라인하기위한 메소드 콜의 검출{DETECTION OF METHOD CALLS TO STREAMLINE DIAGNOSIS OF CUSTOM CODE THROUGH DYNAMIC INSTRUMENTATION}
본 발명은 컴퓨팅 환경에서 소프트웨어를 모니터링하는 기술에 관한 것이다.
인터넷뿐만 아니라 인트라넷 및 익스트라넷(extranet)과 같은 다른 컴퓨터 네트워크들이 점차 확대됨에 따라, 전자 상거래(e-commerce), 교육, 및 다른 분야에서 수많은 새로운 어플리케이션들이 등장하게 되었다. 조직체(organization)들은 그들의 사업들 혹은 다른 목적들을 수행하기 위하여 이러한 어플리케이션들에 점점 더 의지하고 있으며 이러한 어플리케이션들이 기대한 대로 실행되고 있는지를 식별하기 위해서 상당한 자원을 할당하고 있다. 이러한 목적을 위해서, 다양한 어플리케이션 관리 기법들이 개발되었다.
하나의 접근법은 어플리케이션에서 인보크(invoke)되는 개별 소프트웨어 컴포넌트들에 관한 어플리케이션 런타임 데이터를 수집함으로써 어플리케이션의 인프라스트럭쳐를 모니터링하는 것을 포함한다. 이러한 접근법은 모니터링되는 시스템에 본질적으로 상주하는 에이젼트들을 이용할 수 있다. 예컨대, 소프트웨어의 인스트루먼테이션을 이용하여, 쓰레드 또는 프로세스는 인보크되는 각 컴포넌트들을 트레이스(trace)함은 물론 각 컴포넌트의 실행시간과 같은 그러한 런타임을 얻기 위하여 트레이싱된다. 트레이싱이란 컴퓨터 프로그램이 실행하는 단계들의 세부 기록, 즉 트레이스를 얻는 것을 지칭한다. 트레이스의 한 유형은 스택 트레이스이다. 트레이스들은 디버깅에 있어서 보조책으로서 이용될 수 있다. 그러나, 어떤 컴포넌트들을 인스트루먼트할지를 결정하는 것은 문제가 될 수 있다. 오버 인크루시브 접근법(over inclusive approach)은 오버헤드 코스트를 과도하게 함은 물론 어플리케이션의 동작에 손상을 줄 수도 있는 결과를 초래하는 반면, 언더 인크루시브 접근법(under inclusive approach)은 중요한 성능 데이터를 누락시키는 결과를 초래한다. 결과적으로, 소프트웨어의 분석 및 진단이 문제가 있을 수 있다.
본 발명은 상기 및 기타 문제점들을 해소하기 위한 소프트웨어를 분석하는 기술을 제공하는 것이다.
일 실시예에서, 컴퓨터에 의해 실시되는 단계들을 포함하는 어플리케이션을 분석하는, 컴퓨터에 의해 실시되는 방법은 어플리케이션의 코드를 컴퓨터 시스템의 메모리에 로딩하는 단계와, 상기 로딩은 상기 어플리케이션의 코드를 인스트루먼트 메소드들(instrumented methods)을 포함한 인스트루먼트 컴포넌트들의 베이스라인 세트로 구성하는 것을 포함하며, 상기 어플리케이션 코드는 또한 언인스트루먼트 메소드들(uninstrumented methods)을 포함하며; 상기 메모리에서 상기 어플리케이션의 코드를 실행하는 동안, 상기 인스트루먼트 메소드들로부터 성능 데이터를 얻는 단계와; 상기 성능 데이터에 근거하여, 세부적인 분석을 위해 상기 인스트루먼트 메소드들중 적어도 하나를 선택하는 단계와; 상기 선택에 근거하여, 상기 적어도 하나의 선택된 인스트먼티드 메소드에 의해 참조되는 언인스트루먼트 메소드들중 하나 이상의 참조 메소드를 식별하는 단계와, 여기서 상기 식별하는 단계는, 상기 메모리에 로딩된 클래스들중으로부터 상기 적어도 하나의 선택된 인스트루먼트 메소드의 클래스를 결정하고, 자원 위치(715)로부터 상기 메모리내로 상기 클래스의 바이트 코드 리프리젠테이션을 로딩하고, 인보크 바이트 코드의 하나 이상의 인스턴스들을 식별하기 위해 상기 클래스의 바이트 코드 리프리젠테이션을 파싱하고, 그리고 상기 인보크 바이트 코드의 하나 이상의 인스턴스들에 근거하여 상기 하나 이상의 참조된 메소드들을 식별하는 것을 포함하며; 그리고 상기 식별하는 단계에 응답하여, 상기 하나 이상의 참조 메소드들에 대한 어플리케이션의 코드를 상기 인스트루먼테이션으로 구성하는 것을 포함, 상기 적어도 하나의 참조 메소드들을 상기 메모리 내에 로딩하는 단계를 포함한다.
다른 실시예에서, 어플리케이션을 분석하는 방법을 수행하도록 적어도 하나의 프로세서를 프로그래밍하는 컴퓨터 판독가능 소프트웨어가 수록된 컴퓨터 판독가능 저장 장치로서, 상기 방법은 어플리케이션의 코드를 컴퓨터 시스템의 메모리(240)에 로딩하는 단계와, 상기 로딩은 상기 어플리케이션의 코드를 인스트루먼트 메소드들을 포함한 인스트루먼트 컴포넌트들의 베이스라인 세트로 구성하는 것을 포함하며, 상기 어플리케이션 코드는 또한 언인스트루먼트 메소드들를 포함하며; 상기 메모리에서 상기 어플리케이션의 코드를 실행하는 동안, 상기 인스트루먼트 메소드들로부터 성능 데이터를 얻는 단계와; 상기 성능 데이터에 근거하여, 세부적인 분석을 위해 상기 인스트루먼트 메소드들 중 적어도 하나를 선택하는 단계와; 상기 선택에 근거하여, 상기 적어도 하나의 선택된 인스트먼티드 메소드에 의해 참조되는 언인스트루먼트 메소드들중 하나 이상의 참조 메소드를 식별하는 단계와, 여기서 상기 식별하는 단계는, 상기 메모리에 로딩된 클래스들중으로부터 상기 적어도 하나의 선택된 인스트루먼트 메소드의 클래스를 결정하고, 자원 위치로부터 상기 메모리내로 상기 클래스의 바이트 코드 리프리젠테이션을 로딩하고, 인보크 바이트 코드의 하나 이상의 인스턴스들을 식별하기 위해 상기 클래스의 바이트 코드 리프리젠테이션을 파싱하고, 그리고 상기 인보크 바이트 코드의 하나 이상의 인스턴스들에 근거하여 상기 하나 이상의 참조된 메소드들을 식별하는 것을 포함하며; 그리고 상기 식별하는 단계에 응답하여, 상기 하나 이상의 참조 메소드들에 대한 어플리케이션의 코드를 상기 인스트루먼테이션으로 구성하는 것을 포함, 상기 적어도 하나의 참조 메소드들을 상기 메모리 내에 로딩하는 단계를 포함한다.
또 다른 실시예에서, 소프트웨어 명령들을 저장하는 저장 장치와; 상기 저장 장치로부터의 소프트웨어 명령들을 자신에 로드하는 작업 메모리와; 그리고 상기 소프트웨어 명령들을 실행하는 프로세서를 포함하는 컴퓨터 시스템에서, 상기 소프트웨어 명령들은 실행시, 어플리케이션의 코드를 컴퓨터 시스템의 작업 메모리(240)에 로딩하는 단계와, 상기 로딩은 상기 어플리케이션의 코드를 인스트루먼트 메소드들(C1-C7)을 포함한 인스트루먼트 컴포넌트들의 베이스라인 세트로 구성하는 것을 포함하며, 상기 어플리케이션 코드는 또한 언인스트루먼트 메소드들(C4A)를 포함하며; 상기 메모리에서 상기 어플리케이션의 코드를 실행하는 동안, 상기 인스트루먼트 메소드들로부터 성능 데이터를 얻는 단계와; 상기 성능 데이터에 근거하여, 세부적인 분석을 위해 상기 인스트루먼트 메소드들(C4A)중 적어도 하나를 선택하는 단계와; 상기 선택에 근거하여, 상기 적어도 하나의 선택된 인스트먼티드 메소드에 의해 참조되는 언인스트루먼트 메소드들 중 하나 이상의 참조 메소드를 식별하는 단계와, 여기서 상기 식별하는 단계는, 상기 메모리에 로딩된 클래스들중으로부터 상기 적어도 하나의 선택된 인스트루먼트 메소드의 클래스를 결정하고, 자원 위치로부터 상기 메모리내로 상기 클래스의 바이트 코드 리프리젠테이션을 로딩하고, 인보크 바이트 코드의 하나 이상의 인스턴스들을 식별하기 위해 상기 클래스의 바이트 코드 리프리젠테이션을 파싱하고, 그리고 상기 인보크 바이트 코드의 하나 이상의 인스턴스들에 근거하여 상기 하나 이상의 참조된 메소드들을 식별하는 것을 포함하며; 그리고 상기 식별하는 단계에 응답하여, 상기 하나 이상의 참조 메소드들에 대한 어플리케이션의 코드를 상기 인스트루먼테이션으로 구성하는 것을 포함, 상기 적어도 하나의 참조 메소드들을 상기 메모리 내에 로딩하는 단계를 포함한다.
도 1은 관리 어플리케이션을 포함하는 시스템도이다.
도 2는 도 1의 네트워크의 컴퓨터 시스템도이다.
도 3은 실행 경로에서의 컴포넌트들의 콜링 관계를 보인 도면이다.
도 4a는 도 3의 콜링 관계에 근거한 제 1 콜 스택 위치 대 시간 그래프를 보인 것이다.
도 4b는 도 3의 콜링 관계에 근거한 제 2 콜 스택 위치 대 시간 그래프를 도시한 것으로서, 여기서 컴포넌트 C5A가 식별 및 인스트루먼트된다.
도 4c는 JAVA 런타임 환경을 도시한 것이다.
도 5a는 스태틱 인스트루먼테이션을 위한 예시적인 JAVA 기반 프로세스 흐름을 보인 것이다.
도 5b는 스태틱 인스트루먼테이션을 위한 예시적인 .NET 기반 프로세스 흐름을 보인 것이다.
도 6은 콜가능 메소드들을 식별함으로써 소프트웨어를 분석하는 방법을 보인 것이다.
도 7은 도 6과 관련하여 사용될 수 있는 소프트웨어 및 하드웨어를 도시한 것이다.
도 8은 소프트웨어를 인스트루먼팅하는 예시적인 프로세스 흐름을 보인 것이다.
도 9는 컴포넌트들과 대응하는 성능 데이터들 간의 계층적 관계를 나타내는 유저 인터페이스 디스플레이를 도시한 것으로서, 이에 의해 유저는 인스트루먼트될 컴포넌트를 수동으로 식별할 수 있다.
도 10은 도 6의 단계 600을 보다 세부적으로 보인 도면이다.
도 11은 도 6의 단계 640을 보다 세부적으로 보인 도면이다.
도 12은 도 6의 단계 640을 보다 세부적으로 보인 도면이다.
도 13은 도 11의 단계 1125를 보다 세부적으로 보인 도면이다.
도 14은 도 6의 단계 640을 보다 세부적으로 보인 도면이다.
본 발명은 소프트웨어를 분석하는 기법을 제공하는 것으로서, 이에 의해 소프트웨어의 런타임 동안 언인스트루먼트 컴포넌트들이 디스커버 및 동적으로 인스트루먼트될 수 있다. 먼저, 어플리케이션과 같은 그러한 소프트웨어는 메소드들과 같은 그러한 인스트루먼트 컴포넌트들의 베이스라인 세트로 구성될 수 있다. 이 어플리케이션이 실행될 때, 성능 데이터가 상기 인스트루먼테이션으로부터 수집되며, 어떤 메소드들의 수행이 기대에 못 미치거나 아니면 문제가 되는지를 알 수가 있다. 문제를 분석하기 위해, 문제의 메소드로부터 콜가능 메소드들을 디스커버하는 기법이 이용될 수 있다. 특별한 실시예에서, 상기 콜가능 메소드들은 JAVA 가상 머신(JVA)으로 로드된 클래스들의 바이트 코드를 검사함으로써 디스커버될 수 있다. 그 후, 디스커버된 메소드들을 인스트루먼트 및/또는 보고하기 위한 판단이 이루어진다. 인스트루먼테이션을 선택적으로 추가함으로써, 초기에 오버-인크루시브 인스트루먼테이션을 요함이 없이 성능 문제에 대한 정밀 진단을 가능하게 하는 추가적인 성능 데이터가 상기 디스커버된 컴포넌트들로부터 얻어질 수 있다. 따라서, 효율적이며 경량(lightweight)의 인스트루먼테이션의 목표들이 필요 시 정밀 분석을 위한 성능으로 달성될 수 있다.
도 1은 여러 개의 컴퓨터 시스템들이 관리자에 데이터를 제공할 수 있는 네트워크를 도시한 것이다. 예시적인 컴퓨터 시스템들은 어플리케이션 서버(106 및 110), 또는 원하는 기능을 달성하기 위한 코드를 실행하는 프로세서를 갖는 어떤 다른 타입의 컴퓨터 시스템을 포함한다. 이 어플리케이션 서버들은 서로 다른 어플리케이션들 혹은 동일 어플리케이션의 개별 인스턴스들을 실행할 수 있다. 이 어플리케이션 서버들은 서로 원격으로 위치하거나 혹은 함께 위치될 수 있다. 본 실시예에서, 어플리케이션 서버들(106, 110)은 로컬 관리자 컴퓨터(120)와 통신한다. 로컬 관리자 컴퓨터(120)는 대안적으로 상기 어플리케이션 서버들(106, 110)과 원격으로 위치될 수 있으며, 이 경우에, 이들 간의 통신은 네트워크 클라우드(104)를 통해 발생한다.
예컨대, 웹-기반의 전자 상거래 어플리케이션과 같은 그러한 엔터프라이즈 어플리케이션을 실행하는 기업은 로드 밸런싱(load balancing)을 위해 한 위치에서 다수의 어플리케이션 서버들을 활용할 수 있다. 유저들(예컨대, 유저의 예시적인 웹브라우저(105))로부터의 요청들이 네트워크 클라우드(104)(예컨대, 인터넷)을 통해 수신되어, 어플리케이션 서버들(106, 110)중 어느 것에 라우팅될 수 있다.
웹 브라우저(102)는 전형적으로, 인터넷 서비스 프로바이더(미도시)를 통해 네트워크에 클라우드(104)에 액세스한다. 어플리케이션 서버들(106, 110)상에서 실행되는 에이전트 소프트웨어 (각각 에이전트 A1(108)과 에이전트A2(112)로 표시됨)은 하나의 가능한 접근법으로서, 각각의 어플리케이션 서버(106, 110)에서 실행되는 어플리케이션, 미들웨어 혹은 다른 소프트웨어로부터 정보를 수집한다. 예컨대, 그러한 정보는 인스트루먼테이션을 이용하여 얻어질 수 있으며, 이 인스트루먼테이션의 일 예는 바이트 코드 인스트루먼테이션일 수 있다. 그러나, 상기 수집 데이터는 다른 방식으로도 또한 얻어질 수 있다. 상기 에이전트들은 본질적으로 모니터링되는 컴퓨터내에 상주하며, 데이터 취득 포인트(data acquisition point)를 제공한다. 에이전트들은 관리자(120)에 통신되는 데이터를 편성 및 최적화한다.
소프트웨어의 실행을 모니터링하기위해 이 소프트웨어를 인스트루먼트하는 다양한 접근법들이 알려져 있다. 예컨대, 서두에 언급한 바와같이, 트레이싱은 소프트웨어의 실행을 추적하는데 이용된다. 트레이싱의 일 예가 발명 명칭이 "Transaction Tracer"이고 2004년 4월 22일자로 공개된 미국 특허출원 공개번호 2004/0078691에 제시되어 있는 바, 이 공개 문헌의 개시 내용은 본 명세서에 참고로서 포함된다. 이 공개 문헌에 개시된 하나의 접근법에서, 모니터링될 어플리케이션의 객체 코드 또는 바이트 코드가 프로브들로 인스트루먼트(예컨대 수정)된다. 이 프로브들은 어플리케이션의 비지니스 혹은 기타 로직을 변경함이 없이 이 어플리케이션에 관한 특정 정보를 측정한다. 일단 프로브들이 어플리케이션의 바이트 코드에 인스톨되었으면, 이는 관리 어플리케이션으로 칭해진다. 에이전트 소프트웨어는 프로브들로부터 성능 데이터와 같은 그러한 정보를 수신하고 예컨대 관리자(120)에서 다른 프로세스에 이 정보를 통신할 수 있으며, 예컨대 상기 정보가 비정상적인 조건을 표시하는지를 판단하기위해 상기 정보를 국부적으로 처리한다. 예컨대, 프로브들로부터의 정보는 트랜잭션 또는 기타 실행 흐름의 시작 및 정지 시간 즉, 트랜잭션/실행 흐름내에서의 개별 컴포넌트들의 시작 및 정지시간과 같은 그러한 성능 데이터를 표시한다. 이 정보는 이것이 바운드들 내에 있는지를 판단하기 위하여 사전 설정된 기준과 비교될 수 있다. 만일 이 정보가 바운드들 내에 있지 않으면, 상기 에이전트는 적절한 문제 해결이 강구될 수 있도록 이 사실을 관리자에게 통보한다. 에이전트(108, 112 및 116)는 각각, 전형적으로 그들과 관계하는 로컬 어플리케이션 서버(106, 116)에서의 상기 소프트웨어 실행을 인지한다.
관리자(120)는 상기 에이전트들로부터 수신된 데이터에 근거하여 정보를 디스플레이하기 위해 모니터 등의 유저 인터페이스(122)와 통신하는 워크스테이션등의 개별 컴퓨터 시스템에 제공될 수 있다. 도 4a-c 및 도 9의 예시적인 디스플레이를 참조 바란다. 관리자는 또한 상기 에이전트들로부터 수신된 데이터를 저장하기 위해 데이터베이스(118)를 엑세스할 수 있다. 제시된 예에서, 어플리케이션 서버는 네트워크 클라우드(104)에 엑세스함이 없이 관리자(120)와 통신할 수 있다. 예컨대, 상기 통신은 LAN(local area network)을 통해 발생할 수 있다. 다른 설계들에서, 관리자(120)는 네트워크 클라우드(104)를 통해 다수의 어플리케이션 서버의 에이전트들로부터 데이터를 수신할 수 있다, 예컨대, 일부 큰 조직체들은 중앙 네트워크 오퍼레이션 센터를 활용하며, 이 센터들에서 하나 이상의 관리자들이 서로 다른 지리적 위치들에 있는 다수의 분산 에이전트들로부터 데이터를 얻는다. 예시를 위해, 웹-기반 전자 상거래 엔터프라이즈는 고객 주문들을 수신하는 서로 다른 여러 지리적 위치들에 있는 서버들 (예컨대, 페이먼트를 처리하는 서버들, 재고를 추적하여 주문들을 운반하는 웨어하우스들 내의 서버들 및 기타)로부터 에이전트 데이터를 얻는다. 관리자(120) 및 유저 인터페이스 디스플레이(122)는 기업의 본부 위치에 제공될 수도 있다. 반드시 웹-기반일 필요는 없거나 혹은 리테일 또는 다른 세일즈를 포함하는 수반하는 기타 어플리케이션들도 마찬가지로 그들의 시스템을 관리하기 위한 에이전트들 및 관리자들을 활용할 수 있다. 예컨대, 은행은 체크 및 크레디트 어카운트들을 처리하기 위한 어플리케이션을 활용할 수 있다. 더욱이, 전술한 다중-컴퓨터 시스템 구성들에 부가적으로, 하나 이상의 에이전트를 갖는 단일 컴퓨터 시스템이 모니터링될 수 있다.
도 2는 도 1의 네트워크의 컴퓨터 시스템을 도시한 것이다. 컴퓨터 시스템(200)은 도 1과 관련하여 설명된 웹 브라우져(102), 호스트(예컨대, 어플리케이션 서버(106, 110)), 중앙 관리자(120) 및/또는 유저 인터페이스(122)로서 사용될 수 있는 시스템을 개략적으로 나타낸 것이다. 컴퓨터 시스템(200)은 하드 디스크 또는 휴대형 매체등과 같은 그러한 저장 디바이스(210), 다른 컴퓨터 시스템들과 통신하는 네트워크 인터페이스(220), 소프트웨어 명령들을 실행하는 프로세서(230), 예컨대 상기 저장 디바이스(210)로부터 로드된 후 상기 소프트웨어 어플리케이션을 저장하기 위한 RAM과 같은 그러한 작업 메모리(240) 및 유저 인터페이스 디스플레이(250)을 포함한다. 저장 디바이스(210)는 여기서 설명하는 기능들을 제공하는 방법들을 수행하도록 프로세서(230)를 프로그래밍하기 위한 프로세서 판독가능 코드가 수록된 프로세서 판독가능 저장 디바이스인 것으로 고려될 수 있다. 유저 인터페이스 디스플레이(250)는 하나 이상의 에이전트로부터 수신된 데이터에 근거하여 인간 오퍼레이터에 정보를 제공할 수 있다. 유저 인터페이스 디스플레이(250)는 그래픽으로 나타내건, 표로 나타내건 간에 관계없이 모든 알려진 디스플레이 방식을 이용할 수 있다. 온-스크린 디스플레이에 부가적으로, 예컨대, 프린터로부터 등의 하드 카피등의 출력이 제공될 수 있다.
더욱이, 여기에 기술한 기능은 하드웨어, 소프트웨어, 또는 이들의 조합을 이용하여 인스트루먼트될 수 있다. 소프트웨어의 경우, 하나 이상의 프로세서를 프로그래밍하기 위한 프로세서 판독가능 코드가 수록된 하나 이상의 프로세서 판독가능 저장 디바이스들이 사용될 수 있다. 프로세서 판독가능 저장 디바이스들은 휘발성 및 비휘발성 매체, 제거가능 및 제거불가 매체 등의 컴퓨터 판독가능 매체를 포함할 수 있다. 예컨대, 컴퓨터 판독가능 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터 등의 정보를 저장하기 위한 어떤 메소드 또는 기술에서 실시되는 휘발성 및 비휘발성 매체, 제거가능 및 제거 불가 매체를 포함할 수 있다. 컴퓨터 판독가능 매체의 예로서, RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술; CD_ROM, DVD 또는 기타 광 디스크 저장 디바이스, 자기 카세트 디바이스, 자기 테이프, 자기 디스크 저장 디바이스, 또는 기타 광 디스크 저장 디바이스; 혹은 원하는 정보를 저장하는데 이용될 있으며 컴퓨터에 의해 엑세스될 수있는 기타 매체들이 있다. 대안적인 실시예들에서, 일부 또는 모든 소프트웨어는 커스텀 집적회로들, 게이트 어레이들, FPGA들, PLD들 및 특수 목적의 프로세서들을 포함하는 전용 프로세서들로 대체될 수 있다. 일 실시예에서, 하나 이상의 실시예들을 인스트루먼트하는 (저장 디바이스에 저장되는) 소프트웨어가 하나 이상의 프로세서들을 프로그래밍하는데 사용될 수 있다. 이들 하나 이상의 프로세서들은 하나 이상의 컴퓨터 판독가능 매체/저장 디바이스들, 주변기기 및/또는 통신 인터페이스들과 통신할 수 있다.
도 3은 실행 경로에 있어서 컴포넌트들의 콜 관계들을 도시한 것이다. 컴포넌트들은 도 1의 어플리케이션 서버(106 또는 110)와 같은 어플리케이션 서버상에서 실행될 수 있는 어플리케이션에서 도시되어 있다. 본 명세서에서 제공되는 컴포넌트들의 순서는 실행 경로의 하나의 가능한 유형의 예이다. 인보크되는 각 컴포넌트는 실행 경로의 일부로 여겨질 수 있다. 유의할 점은 어플리케이션이 인스트루먼트될 때 전형적으로 선택된 컴포넌트들만이 어플리케이션에 대한 개발자의 이해와 관심거리로 예상되는 컴포넌트들의 선택에 근거하여 인스트루먼트된다는 것이다. 따라서, 관심거리라고 여겨지지 않는 많은 컴포넌트들은 적어도 초기에 어플리케이션에서 인보크될 수 있지만, 실행 경로에서는 포함되지 않는다.
컴포넌트 지향 프로그래밍 모델들은 프로그래머로 하여금 컴포넌트들이라고 지칭되는 빌딩 블록들로부터 어플리케이션이나 다른 프로그램을 조합할 수 있게 하는데 있어 유용하다. 각 컴포넌트는 소프트웨어의 전반적인 기능과 맞아들어가는 특정 기능을 수행할 수 있다. 또한, 컴포넌트는 재귀적 콜로 그 자신을 콜할 수 있을 뿐만 아니라 다른 컴포넌트들을 콜할 수 있으므로, 컴포넌트들의 순서는 프로그램에서 인보크된다. 컴포넌트들은 프로그램이 실행될 때 소비되는 컴퓨터 시스템에서의 자원들의 예들이거나 처리된 작업이다. 컴포넌트 지향 프로그래밍 모델의 한 예는 J2EE이며, Java Server Page, Enterprise Java Bean, 서블릿(servlet) 및 Java Database Connectivity 컴포넌트와 같은 컴포넌트들을 채용할 수 있다. 하지만, Microsoft .NET 컴포넌트들을 이용하는 것과 같은 다른 컴포넌트 지향 프로그램 모델도 또한 이용될 수 있다. 게다가, 프로그래밍 모델은 객체 지향일 필요가 없다. 한 접근법에서는, 컴포넌트들이 메소드(method)들로 여겨진다.
도시된 특정 예는 사용자들로 하여금 아이템들을 주문할 수 있도록 해주는 웹-기반 전자 상거래(web-based e-commerse) 어플리케이션을 가리킨다. 컴포넌트들은 어플리케이션에서 비지니스 로직이나 전자 상거래 단계들에 해당한다. 특히, 컴포넌트 C1(312)는 사용자로 하여금 구매할 아이템을 선택하도록 해주고 결제 수단, 예컨대 신용 카드의 종류나 신용 카드 번호와 같은 정보를 입력하도록 해주는 쇼핑 카트와, 선적 정보, 예컨대 아이템이 선적될 주소와 선적 방법, 예컨대 육상 배송이나 야간 항공 배송을 제공한다. C1(312)은 선택된 아이템이 재고가 있는지를 판별하기 위해 인벤토리를 체크하도록 컴포넌트 C1A(314)를 콜한다. 선택된 아이템이 재고가 있는 것으로 판별되면, C1(312)는 컴포넌트 C2(322)를 콜하며, 트랜잭션이 여전히 계류중일 동안에 다른 사용자에게 팔리지 않도록 아이템을 리저브한다. 완료되면, C2(322)는 컴포넌트 C3(324)를 콜하며, 이는 구매를 인가하고 승인하기 위하여 사용자의 신용 카드 정보를 체크한다. 이것은 전형적으로 신용 카드 크리어링하우스에 의해 관리되는 외부 서버와 통신하는 것을 수반한다. 예를 들면, C3(324)는 신용 카드 서비스와 컨택하는 컴포넌트 C3A(326)를 콜할 수 있다.
C3(324)가 성공적으로 완료됨으로써 구매를 인가하면, 구매된 아이템의 개수를 감소시킴으로써 인벤토리를 조정하는 컴포넌트 C4(330)를 콜한다. C4(330)는 창고를 컨택하는 것과 같이 아이템이 선적되는 것을 처리하는 컴포넌트 C5(342)를 콜하며, 여기서 선적 라벨이 프린트되고 오퍼레이터가 아이템을 수동으로 찾고 포장하도록 준비한다. 예를 들면, C5(342)는 창고 A를 컨택하는 컴포넌트 C5A(344) 및/또는 창고 B를 컨택하는 컴포넌트 C5B(346)를 콜할 수 있다.
일단 컴포넌트들 C2-C5가 실행되면, 실행 경로는 C1(312)로 돌아가며, 예컨대 확인 이메일이나 웹페이지에서 주문 확인 번호와 추적 번호를 제공하는 것과 같이 구매를 사용자에게 확인시키기 위하여 주문 완료 컴포넌트 C6(316)을 콜한다. C1A(314)에서 인벤토리가 재고가 없거나 C3(324)에서 신용 카드 지불이 성공적이지 못하면 실행 경로는 유사하게 C1(312)으로 돌아갈 수 있다. 하나의 가능한 구현에서는, C1과 C6가 Java Server Page들이고 C2-C5는 Enterprise JavaBeans이다.
주목할 사항으로서, 제1 컴포넌트가 다른 컴포넌트를 콜한 후에 실행을 속행할 수 있으며, 비동기로, 다중-쓰레드로, 또는 다중-프로세스 모드로 실행을 시작하거나 콜된 컴포넌트가 동기로, 단일-쓰레드로, 또는 단일-프로세스 모드로 실행을 완료할 때까지 임시적으로 정지할 수 있다. 예를 들면, C1(312)은 컴포넌트들 C2-C5가 실행하는 동안에 정지할 수 있다. 게다가, 주어진 컴포넌트는 트랜잭션 동안에 한번보다 많이 인보크될 수 있다. 예를 들면, 사용자가 서로 다른 창고들에 저장되어 있는 복수의 아이템들을 구매했다고 가정하자. 이 경우에, C5(342)는 반복적으로 실행될 수 있고, 각 아이템에 대하여 서로 다른 창고 및/또는 창고 부서를 컨택할 수 있다.
도 4A는 도 3의 콜 관계들에 근거하여 제1 콜 스택 위치 대 시간 그래프를 도시한 것이다. 시간 증분들은 반드시 동일한 간격이지는 않다. 표현, 트랜잭션 트레이스는 하나 이상의 호스트들에 의해 제공되는 실행 경로 정보의 종류의 예이다. 예를 들면, 그것은 사용자 인터페이스 상에서 보고로서 제공되는 그래픽 표현일 수 있고, 메소드들과 같은 컴포넌트들의 실행 시간들의 형태로 성능 데이터를 표현한다. 실행 경로 정보는 어플리케이션의 어떤 메소드들이 인보크되고 이들이 인보크된 시간을 식별할 수 있다. 수평 방향은 시간을 표현하는 반면, 수직 방향은 콜 스택 깊이나 위치를 가리킨다. 콜 스택은 하나 이상의 프로그램들이나 쓰레드들을 실행하는 동안에 콜되거나 인보크된 메소드들을 식별한다. 실행 경로는 전형적으로 초의 일부에서 수 초간 연장될 것이다.
예시적인 실행 경로는 순서, C1 (412), C1A (414), C1 (412), C2 (422), C3 (424), C3A (426), C3 (424), C4 (430), C5 (442), C4 (430), C3 (424), C2 (422), C1 (412), C6 (416) , C1 (412)을 포함한다. 호스트 장치는 클라이언트로부터 요청을 수신하고 t1에서 C1이 실행을 시작하는 때를 주목한다. 순서에서 각각의 천이는 인스트루먼테이션에 근거하여 에이전트에 의해 주목된다. t2에서 C1은 C1A를 콜한다. t4에서 C1A는 실행을 완료한다. t5에서 C1은 C2를 콜한다. t6에서 C2는 C3를 콜한다. t7에서 C3는 C3A를 콜한다. t9에서 C3A는 실행을 완료한다. t10에서 C3는 C4를 콜한다. t11에서 C4는 C5를 콜한다. t16에서 C5는 실행을 완료한다. t17에서 C4는 실행을 완료한다. t18에서, C3는 실행을 완료한다. t19에서 C2는 실행을 완료한다. t20에서 C1은 C6를 콜한다. t24에서 C6는 실행을 완료한다. t25에서 호스트는 클라이언트에 응답을 제공하며, 그 때 C1은 실행을 완료한다. 호스트는 주기적으로 시간과 트랜잭션 데이터를 중앙 관리자에게 보고한다.
도 4B는 도 3의 콜 관계들에 근거하여 제2 콜 스택 위치 대 시간 그래프를 도시한 것이며, 컴포넌트 C5A가 식별되며 인스트루먼트된다. 예로서, 응답 시간과 같은 성능 데이터가 t16-111인 C5(442)의 응답 시간이 너무 길어서 임계 레벨을 초과한 것을 가리킨다고 가정하자. 이 경우에, C5에 의해 콜될 수 있는 어떤 메소드들에 관한 어떤 정보도 알려져 있지 않다. 이 예에서는, 본 명세서에서 서술된 기법들이 컴포넌트/메소드 C5A(444)가 C5로부터 콜가능한 지를 발견하는데 이용된다. 콜가능한 컴포넌트는 다른 컴포넌트에 의해서 콜될 수 있지만 반드시 그러하지는 않는다. C5에 의해 직접 콜된 메소드는 차일드 메소드로 여겨질 수 있는 반면, C5의 차일드 메소드에 의해 콜된 메소드는 C5의 그랜드차일드 메소드 등이다. 콜가능한 메소드가 식별되면, 그것으로부터 성능 데이터를 얻도록 인스트루먼트될 수 있다. 하지만, 이러한 인스트루먼테이션은 콜가능한 메소드가 또한 다른 수단에 의해 분석되어 보고될 수 있기 때문에 요구되지 않는다.
이 경우에, C5A는 발견된 후에 인스트루먼트되고, 어플리케이션은 새로운 성능 데이터가 모아지도록 실행을 속행한다. 서로 다른 메소드 인보케이션 인스턴스들을 나타내고 도 4B의 시간 t1-t25가 도 4A의 시간 t1-t25후에 발생한다 하더라도, 간결함을 위해 도 4B의 콜 스택 위치 대 시간 그래프는 도 4A에서와 동일한 것으로 가정된다. 그래프는 t12에서 C5가 C5A(444)를 콜했고, t15까지 C5A가 실행하여서, C5A의 응답 시간은 t15-t12라는 것을 가리킨다. 이는 어플리케이션을 진단하고 분석하는데 중요한 도움을 제공할 수 있다. 예를 들면, C5A는 초과 실행 시간에 대한 이유라고 결론질 수 있다. 메소드 발견 프로세스는 또한 C5B가 C5로부터 콜가능한지를 판별할 수 있다. 도 4B의 예에서는, C5B가 그에 더해지는 인스트루먼테이션을 가지는 것으로 가정할 수 있다. 하지만, 이 예에서 콜되지 않았기 때문에, C5B는 초과 실행 시간에 대한 이유가 아닌것으로 결론질 수 있다. 이것은 달리 이용가능하지 않았을 중요한 진단 정보이다.
도 4C는 JAVA 런타임 환경을 도시한 것이다. JAVA 런타임 환경(484)는 운영 체제(482) 상에서 빌드되며, 하드웨어(480) 상에서 빌드된다. JAVA 런타임 환경(484)은 JAVA API Class(486)과 JVM(488)을 포함하여 몇 개의 가상 부분들을 포함한다. JVM은 레지스터들(490), 오퍼랜드 스택(492), 히프(494) 및 메소드 영역(496)을 포함한다. JVM은 일련의 명령어들로서 바이트 코드들의 스트림을 처리한다. JVM 명령어들은 수행될 동작을 특정하는 오피코드로 구성되며, 제로 또는 그 이상의 오퍼랜드 포함 값들이 실행되도록 따른다. 오퍼랜드 스택(492), 히프(494), 메소드 영역(496)은 어드레스 가능한 메모리 내에 있다. 어드레스의 크기는 32 비트이고, 각 메모리 위치는 한 바이트를 포함하고, 각 레지스터는 하나의 32 비트 어드레스를 저장한다. 메소드 영역(496)은 바이트 코드들을 포함하고 바이트 경계 상에서 정렬되는 반면, 오퍼랜드 스택(492)와 히프(494)는 워드(32 비트) 경계에서 정렬된다.
레지스터들(490)은 프로그램 카운터(pc)를 포함하고, 이는 메모리에서 명령어들을 실행해야되는 곳을 계속 추적한다. 프로그램 카운터는 실행될 다음 바이트 코드를 식별한다. 프레임 레지스터는 오퍼랜드 스택에서 현재 메소드의 실행 환경에 대한 포인터를 포함한다. 오퍼랜드 탑(optop) 레지스터는 오퍼랜드 스택의 탑에 대한 포인터를 포함하고, 연산 표현들을 평가하는데 이용된다. 변수(vars) 레지스터는 지역 변수들에 대한 포인터를 포함한다.
오퍼랜드 스택(492)는 메소드와 동작들에 대한 파라미터들을 제공하고 그들로부터 결과들을 수신한다. 모든 바이트 코드 명령어들은 스택으로부터 오퍼랜드들을 취하고, 그들상에서 동작하고 스택에 결과들을 리턴한다. 오퍼랜드 스택은 실행 메소드의 스택 프레임을 포함한다. 스택 프레임은 메소드의 특정 인보케이션에 대한 상태, 예컨대 지역 변수들, 계산의 중간 결과들을 보유한다. 구체적으로, 각 JVM 쓰레드는 프라이빗 JVM 스택을 가지고, 쓰레드와 동일 시간에 생성된다. JVM 스택은 프레임들을 저장하고 지역 변수들과 부분적 결과들을 보유하고 메소드 인보케이션과 리턴에 일조한다. 프레임은 따라서 동적 링킹을 수행하고, 메소드에 대한 값들을 리턴하고 예외들을 디스패치하는 것 뿐만 아니라 데이터와 부분적 결과들을 저장하는데 이용된다. 새로운 프레임은 메소드가 인보크될 때마다 생성된다. 프레임은 완료가 정상적이거나 갑작스럽든(잡히지 않는 예외를 보냄) 간에 그 메소드 인보케이션이 완료될 때 파괴된다. 프레임들은 프레임을 생성하는 쓰레드의 JVM 스택으로부터 할당된다. 각 프레임은 지역 변수들의 각자의 어레이, 각자의 오퍼랜드 스택, 그리고 현재 메소드의 클래스의 런타임 상수 풀에 대한 참조를 가진다.
히프(494)나 메모리 할당 풀은 쓰레기가 모아진다. 히프는 모든 클래스 인스턴스들과 어레이들에 대한 메모리가 할당되는 런타임 데이터 영역이다. 히프는 가상 머신 스타트업 상에서 생성되고, 객체들에 대한 히프 저장은 쓰레기 콜렉터라고 알려진 자동 저장 관리 시스템에 의해 재요구된다. 구체적으로, Java 런타임 환경에서 돌아가는 각 프로그램은 그것에 할당되는 쓰레기-모음 히프를 가진다. 게다가, 각 히프의 각 클래스는 그것과 관련된 상수 풀을 가진다. 상수들은 변하지 않기 때문에, 그들은 컴파일 시간에 대체로 생성된다. 상수 풀에 있는 아이템들은 특정 클래스에서 임의의 메소드에 의해 이용되는 모든 이름들을 인코딩한다. 클래스는 얼마나 많은 상수들이 존재하는지에 대한 카운트와, 클래스 설명에서 상수들의 특정 리스트가 어디서 시작하는지를 특정하는 옵셋을 포함한다.
메소드 영역(496)은 컴파일된 코드에서 메소드들과 관련된 바이트 코드 명령어들을 저장하고, 실행 환경이 동적 링킹에 대하여 필요한 심볼 테이블을 저장한다. 메소드와 관련될 필요가 있을 수 있는 임의의 디버깅 정보나 추가 정보가 또한 이 영역에 저장된다. 프로그램 카운터는 항상 메소드 영역의 어떤 바이트를 가리키는데, 예를 들어 어떤 바이트의 어드레스를 가지고 있다. 프로그램 카운터는 쓰레드 실행을 계속 추적하는데 이용된다. 바이트 코드 명령어가 실행된 후에, 프로그램 카운터는 실행할 다음 명령어의 어드레스를 보유한다.
메소드 영역(496)은 모든 JVM 쓰레드들 간에 공유되고, 클래스와 인스턴스 초기화 및 인터페이스 종류 초기화에 이용되는 특별한 메소드를 포함하여, 런타임 상수 풀, 필드 및 메소드 데이터와 같은 클래스당 구조체들과 메소드들과 생성자들에 대한 코드를 저장한다. 메소드 영역은 가상 머신 스타트업 상에서 생성된다. 런타임 상수 풀은 클래스 파일에서 상수 풀 테이블의 클래스당 또는 인터페이스당 런타임 표현이다. 그것은 여러 종류의 상수들을 보유하고, 컴파일시에 알려진 숫자 문자들로부터 런타임에 해결되어야할 메소드 및 필드 참조들까지의 범위를 가진다. 각 런타임 상수 풀은 JVM의 메소드 영역으로부터 할당된다. 클래스나 인터페이스에 대한 런타임 상수 풀은 클래스나 인터페이스가 JVM에 의해 생성될 때 생성된다.
삭제
삭제
삭제
삭제
삭제
도 5A는 스태틱 인스트루먼테이션(staic instrumentation)에 대한 JAVA-기반의 예시적인 프로세스를 도시한다. 하나의 가능한 시도에서, 이러한 프로세스는 도 1의 에이전트(108 또는 112)와 같은 에이전트(500)에 의해 구현될 수 있다. 인스트루먼테이션에 대한 하나의 시도는 어떤 컴포넌트들(이를 테면, 메소드들)이 인스트루먼트(instrument)될 것인 지를 결정하는 스태틱 규칙들(static rules)을 제공하는 것을 수반한다. 이러한 규칙들은 컴포넌트들이 어플리케이션 내에 로드될 때에 액세스된다. 이러한 시도에서, 클래스 로더(520)는 변환기(515)에 어플리케이션 바이트 코드의 원시(raw) 데이터 바이트들을 제공하는 데에 이용되며, 변환기(515)는 이러한 원시 바이트들을, 이를 테면 클래스로 변환한다. 예를 들어, JAVA에서, 이것은 클래스들을 로딩하는 것을 담당하는 ClassLoader 오브젝트의 메소드(method) defineClass를 이용할 것을 필요로 한다. 클래스 ClassLoader는 앱스트랙트 클래스(abstract class)이다. 클래스의 이름이 주어지면, 클래스 로더는 그 클래스의 정의(definition)를 구성하는 데이터의 위치를 찾거나(locate) 또는 이러한 데이터를 발생시키고자 시도해야 한다. 전형적인 방식은 이름을 파일 이름으로 변환한 다음, 파일 시스템으로부터 그 이름의 "클래스 파일"을 읽는 것이다. 상기 메소드 defineClass는 바이트들의 어레이를 클래스 Class의 인스턴스(instance)로 변환한다. 이러한 클래스 Class의 인스턴스들은 실행중인(running) JAVA 어플리케이션에서의 클래스들 및 인터페이스들을 나타낸다. 이에 따라, 변환기(515)는, 이를 테면 클래스들을 변환함으로써, 인스트루먼테이션을 부가하도록 바이트 코드를 변환할 수 있는 소프트웨어이다. 하나의 시도에서, 이러한 변환기(515)의 최소 처리 단위는 클래스 파일 및 그것의 바이트 어레이이다.
만일 결정 블록(510)에서 어플리케이션 바이트 코드가 규칙들(다이렉티브즈)(directives)(505)과 매치한다면, 변환기(515)는 트레이서 바이트 코드(tracer byte code)의 형태로 프로브들(probes)을 부가한다. 만일 결정 블록(510)에서 어플리케이션 바이트 코드가 규칙들(505)과 매치하지 않는다면, 변환기(515)는 바이트 코드에 인스트루먼테이션을 부가하지 않는다. 변환기(515) 및 결정 블록(510)은 프로브 빌더(probe builder)(525)의 일부인 것으로 고려될 수 있다.
이러한 인스트루먼테이션에서, 규칙들(505)은 전형적으로 인스트루먼트되어야 하는 관리되는 어플리케이션의 부분들을 식별하는 스태틱 규칙들의 세트이다. 이러한 규칙들은 일반적으로, 클래스가 가상 머신(virtual machine) 내에서 처음으로 정의될 때에 인스트루먼트된다. 클래스가 단지 한번 정의되는 동안, 이러한 클래스는 다수회 로드될 수 있다. 예를 들어, 동일한 클래스를 로드하는 다수의 클래스 로더들(class loader)이 있을 수 있다. 또한, 클래스들과 같은 컴포넌트들은, 이들이 어떠한 방식으로 명명되는지, 이들이 어떠한 인터페이스를 구현하는지, 이들이 어떠한 서브클래스 또는 수퍼 클래스를 확장시키는지 등등에 기초하여 인스트루먼트될 수 있다. 이러한 컴포넌트들은 인스트루먼트되도록 선택되는데, 그 이유는 이들은 유용한 또는 관심있는(interesting) 성능 데이터(performance data)를 제공하는 것으로 여겨지기 때문이다.
이를 테면, 규칙은 모든 서블릿들(servlets)이 인스트루먼트되어야 함을 나타낼 수 있는데, 왜냐하면 이러한 서블릿들중 적어도 일부는 관심있는 데이터를 제공할 수 있는 것으로 여겨지기 때문이다. 이러한 경우, 규칙들(505)은 JAVA 클래스 HttpServlet의 서브크래스들인 모든 컴포넌트들이 인스트루먼트되어야 함을 나타낼 수 있다. HttpServlet은 모든 서블릿들이 의존하는 앱스트랙트 클래스이다. 하지만, 반드시 모든 컴포넌트들이 인스트루먼트되는 것은 아니며, 그리고 오버 인크루시브 인스트루먼테이션(over-inclusive instrumentation)은 과도한 오버헤드 비용을 야기하고 어플리케이션의 동작을 손상시킬 수 있는 반면, 언더 인크루시브(under-inclusive) 인스트루먼테이션은 중요한 성능 데이터의 생략을 야기할 수 있다는 점에서 부담이 된다.
도 5B는 스태틱 인스트루먼테이션에 대한 .NET-기반의 예시적인 프로세스 흐름을 도시한다. 다른 가능한 시도에서, 관리되는 어플리케이션의 컴포넌트들은 MICROSOFT CORP. ".NET 프레임워크"에 따라 제공된다. JAVA와 달리, .NET 프레임워크는 클래스 로더들을 이용하지 않는다. 대신에, .NET은 그 프레임워크에 대해 특정하게 기록된 프로그램들의 실행을 관리하는 가상 머신을 포함한다. .NET 프레임워크의 런타임 환경은 커먼 랭귀지 런타임(Common Language Runtime, CLR)으로서 알려져있다. 이러한 CLR은, 프로그래머들이 그 프로그램을 실행하게 될 특정의 CPU의 성능을 고려할 필요가 없도록, 어플리케이션 가상 머신의 외관(appearance)을 제공한다. 이러한 CLR은 또한 보안, 메모리 관리 및 예외 취급과 같은 다른 서비스들을 제공한다. 이러한 CLR 및 프리 코드 솔루션들(pre-coded solutions)의 클래스 라이브러리가 .NET 프레임워크를 함께 구성한다.
또한, CLR은 커먼 랭귀지 인프라스트럭춰(Common Language Infrastructure, CLI)의 하나의 구현인데, 이러한 CLI는, 예외 취급, 쓰레기 수집(garbage collection), 보안 및 상호 운용성(interoperability)에 대한 기능들을 포함하여, 어플리케이션 개발 및 실행을 위한 랭귀지 중립의 플랫폼(language-neutral platform)을 제공한다. CLI는 코어 클래스 라이브러리들, 커먼 타입 시스템(Common Type System) 및 커먼 인터미디에이트 랭귀지(Common Intermediate Language, CIL)를 포함한다. JAVA 바이트 코드에 대해, CIL은 인터미디에이트 바이트 코드의 다른 예이다. JAVA 및 .NET 는 단지 예시적인 구현들을 제공하는 것이며, 다른 구현들이 가능하다.
여기서, 하나의 가능한 시도에서, 상기 프로세스는 에이전트(550)에 의해 구현될 수 있다. 하나의 가능한 시나리오에서, .NET 프레임워크의 일부 프로세스는 이름에 의해 클래스를 참조(reference)하며, CLR(570)은 클래스를 찾고, (만일 있는 경우) 이를 변환기(656)에 제시한 다음, 결과적인 CIL을 이용한다. 특히, 결정 블록(560)에서 클래스가 규칙들(555)과 매치하면, 인스트루먼테이션이 부가된다. 만일 결정 블록(560)에서 클래스가 규칙들(555)과 매치하지 않으면, 인스트루먼테이션은 부가되지 않는다. 변환기(565) 및 결정 블록(560)은 프로브 빌더(575)의 일부로서 고려될 수 있다.
도 6은 콜가능한 메소드들(callable methods)을 식별함으로써 소프트웨어를 분석하는 방법을 도시한다. 설명한 바와 같이, 인스트루먼테이션의 양은 과도한 오버헤드를 피할 수 있도록 제한되어야 하며, 이에 따라 어플리케이션의 동작을 이해할 수 있는 능력이 제한된다. 일부 경우들에서는, 어플리케이션을 진단(diagnose)하고자 하는 데에 소스 코드가 이용가능 했던 경우 이러한 소스 코드는 리뷰될 수 있지만, 일반적으로 소스 코드는 이용가능하지 않으며, 대부분의 사용자들은 쉽게 이해할 수 없다. 결과적으로, 사용자는 어플리케이션을 진단하기 위한 적절한 정보를 얻기 위해 어떤 부가적인 메소드들을 인스트루먼트해야 하는 지를 알지 못하게 된다. 대신에, 어플리케이션에 대한 보다 깊은 이해 및 진단은, 현재 인스트루먼트되지 않으며, 이에 따라 눈에 띄지 않는 콜가능한 메소드들을 선택적으로 발견함으로써 달성될 수 있다. 이러한 부가적인 메소드들은 진단 세션 동안 인스트루먼트될 수 있으며, 이후 이러한 인스트루먼테이션은 제거될 수 있다. 여기에서 제공되는 기술들은 또한 맞춤형 소프트웨어(custom software)에 인스트루먼테이션을 부가하는 데에도 유용한데, 여기서 표준의 인스트루먼테이션 패키지는, 인스트루먼테이션이 바람직한 코드의 부분들을 훑어볼 수 있다. 에이전트는 이러한 기술들을 이용하여, 요구시에(on-demand) 특정의 메소드 또는 메소드들의 세트에 의해 콜될 수 있는 코드의 부분들을 발견할 수 있다. 하나의 예시적인 구현에서 바이트 코드 분석이 이용된다.
단계(600)는 분석하기 위한 어플리케이션 내에서 적어도 하나의 메소드를 식별하는 단계를 포함한다. 도 10은 추가의 상세사항들을 제공한다. 이는, 도 5A 및 도 5B와 관련하여 설명된 바와 같이, 컴포넌트들이 어플리케이션 내에 로드될 때 어떤 컴포넌트들(이를 테면, 메소드들)이 인스트루먼트될 것인 지를 결정하는 스태틱 규칙들에 기초하는 것과 같은, 이미 인스트루먼트된 적어도 하나의 메소드가 될 수 있다. 다른 시도에서, 이러한 적어도 하나의 메소드는 어플리케이션 내에 로드된 이후에 인스트루먼트될 수 있다. 이러한 적어도 하나의 메소드는, 이를 테면 이러한 적어도 하나의 메소드에 대한 성능 문제를 나타내는 성능 데이터에 기초하여 식별될 수 있다. 이러한 식별은, 성능 데이터를 연속적으로 모니터하고, 이를 테면 사용자 인터페이스 상에서 사용자에게 보고를 제공함으로써 수행될 수 있다. 예를 들어, 도 9를 참조한다. 미리 설정된 한계치들(preset limits)과의 비교에 기초하여, 범위를 벗어나는 성능 데이터는 자동으로 플래그(flag)된다. 그러면, 사용자는 인스트루먼트하기 위한 하나 이상의 메소드들을 수동으로 선택할 수 있다. 가능한 다른 시도에서, 이러한 프로세스는 완전히 자동화되어, 사용자의 개입을 요구하지 않으며, 이에 따라 식별되는 메소드는 자동으로 인스트루먼트될 수 있다. 단계(605)는 상기 적어도 하나의 메소드의 메소드 콜이 존재하는 지를 결정하기 위해 캐시를 체크하는 단계를 포함한다. 이러한 캐시는, 이를 테면 어플리케이션이 실행 어플리케이션 서버의 에이전트의 가상 머신 내에 있을 수 있다.
일반적으로, 상기 캐시는 실행 성능을 위해 제공될 수 있다. 어플리케이션이 실행되기 시작할 때, 캐시는 비어있다. 상기 단계(600)에서 식별되는 적어도 하나의 메소드는 메소드 doSomething()으로 불린다고 가정한다. 이것의 콜가능한 메소드들을 검색하기 위한 프로세스가 시작된다. 첫번째로 행하는 것은 캐시를 살펴보는 것이다. 결정 단계(610)에서, 만일 캐시 내에 콜가능한 메소드들이 없다면, 단계들(615 내지 635)을 수행하여, 콜가능한 메소드들을 식별한 다음 이들을 캐시에 저장한다. 단계(635)는 doSomething()에 대해 검색된 메소드 콜들을 다음의 의사 코드(pseudo-cahce): cache.put([{classLoader of the class}; {class where the doSomething() method is defined}; doSomething()], [callable method 1, callable method 2 ....])을 이용하여 캐시하는데, 여기서 상기 ([{classLoader of the class}; {class where the doSomething() method is defined}; doSomething()] 은 메소드 doSomething()을 명확하게 식별하는 키(key)이며, 그리고 상기 콜가능한 메소드들은 doSomething()에 대해 식별되는 콜가능한 메소드들이다. 상기 메소드 doSomething()에 대한 절차가 다음번에 활성화될 때에, 상기 캐시는 이전에 검색된 정보를 포함할 것이며, 이에 따라 단계들(615 내지 635)을 더 이상 실행할 필요가 없는데, 왜냐하면 캐시 내에 콜된 메소드에 대한 정보를 가지고 있기 때문이다. 상기 설명한 키에 의해 정보를 검색한다.
따라서, 결정 블록(610)에서, 상기 단계(600)의 적어도 하나의 식별되는 메소드의 콜가능한 메소드들이 하나 이상의 참조 메소드들로서 캐시 내에 있다면, 이러한 하나 이상의 참조 메소드들은 단계(640)에서 보고 그리고/또는 인스트루먼트될 수 있는데, 이에 대해서는 도 11 및 도 12와 관련하여 더 설명된다. 결정 단계(610)에서, 상기 단계(600)의 적어도 하나의 식별되는 메소드의 콜가능한 메소드들이 캐시 내에 없다면, 단계들(615 내지 635)이 수행된다. 단계(615)는 반사(reflection)를 통해 상기 적어도 하나의 메소드의 클래스를 결정한다. 하나의 가능한 시도에서, 이는 JAVA 어플리케이션 프로그래밍 인터페이스(API), java.lang.instrument 를 이용하는 것을 포함한다(단계 617). 상기 적어도 하나의 메소드는 인보킹 메소드(invoking method)인 것으로 고려될 수 있는데, 왜냐하면 이는 하나 이상의 콜가능한 메소드들을 인보크 또는 콜할 수 있기 때문이다. 단계(615)는, 이를 테면 메모리 내의, 예를 들어 JVA 내의 로드된 모든 클래스들로부터 JAVA 클래스를 페치함으로써, 상기 적어도 하나의 메소드의 클래스를 결정하는 것을 포함할 수 있다.
단계(620)는, 이를 테면 바이트 코드가 얻어진 최초의 리소스 위치로부터, 클래스의 바이트 코드 표현을 로드하는 단계를 포함한다. 하나의 예시적인 구현에서는, 이용가능한 경우, JAVA 클래스 ClassLoader가 이용된다(단계 622). 주목할 사항으로서, 단계(620)에서 메모리 내에 로드되는 코드의 양을 제한하기 위해 안전 예방조치(safety precaution)가 실시될 수 있으며, 이에 따라 매우 큰 자동 발생 클래스들이 메모리를 압도하지 않게 될 것이다.
단계(625)는 인보크 바이트 코드의 하나 이상의 인스턴스들을 식별하기 위해 단계(620)에서 얻어진 각 클래스의 바이트 코드 표현을 파싱하는 단계를 포함한다. 특정의 구현에서, 이는 클래스의 바이트 코드 표현 내에서 특정의 오피코드들(연산 코드들)을 식별하는 단계를 포함한다(단계 627). 이를 테면, JAVA 랭귀지 내의 4개의 오피코드들은 다른 메소드를 인보크할 수 있는 바이트 코드를 식별한다. 구체적으로, 인보크버추얼(invokevirtual)에 대한 오피코드는 10진 값 182 또는 16진 값 (0xb6 또는 b6)이고, 인보크스페셜(invokespecial)에 대한 오피코드는 10진 값 183 또는 16진 값 (0xb7 또는 b7)이고, 인보크스태틱(invokestatic)에 대한 오피코드는 10진 값 184 또는 16진 값 (0xb8 또는 b8)이며, 그리고 인보크인터페이스(invokeinterface)에 대한 오피코드는 10진 값 185 또는 16진 값 (0xb9 또는 b9)이다. 이러한 오피코드들중 임의의 오피코드의 존재는 콜가능한 메소드들을 식별한다.
또한, 하나 이상의 특정 오피코드들(하지만, 가능한 모든 오피코드들 보다는 적다)을 검출하도록 단계(625)를 제한하는 것이 가능하다. 이를 테면, 인터페이스 메소드에 관심이 있는 지를 결정할 수 있는데, 이 경우에는 단지 invokevirtual, invokespecial 및 invokestatic에 대한 오피코드들 만이 검출되고, invokeinterface에 대한 오피코드는 검출되지 않는다.
단계(630)는 인보크 바이트 코드의 하나 이상의 인스턴스들에 기초하여 하나 이상의 참조 메소드들을 식별한다. 예시적인 구현에서, 이러한 하나 이상의 참조 메소드들은 단계(615)에서 결정되는 클래스의 상수 풀(constant pool)로부터 추출된다. 구체적으로, 단계(632)는 오피코드들에 기초하여 상수 풀 내에서 엔트리들에 대한 인덱스들을 식별하고, 단계(634)는 이러한 인덱스들에 기초하여 하나 이상의 참조 메소드들을 식별한다. 단계(635)는 이러한 하나 이상의 참조 메소드들을 캐시 내에 스트링으로서, 예를 들어 doSomething()에 대해 콜된 메소드들로서 저장한다. 단계(640)는 이러한 하나 이상의 참조 메소드들을 보고하고 그리고/또는 인스트루먼트하는 단계를 포함하는데, 이에 대해서는 도 11 내지 14와 관련하여 더 설명된다.
주목할 사항으로서, 도 6의 프로세스는 다수의 다른 메소드들 각각에 대해, 동시에 또는 다른 시간에, 개별적으로 수행될 수 있다.
도 7은 도 6의 메소드와 관련하여 이용될 수 있는 소프트웨어 및 하드웨어(집합적으로 700으로 나타냄)를 도시한다. 하드웨어는 다이내믹 인스트루먼테이션 캐시(dynamic instrumentation cache)(702) 및 메모리 리소스(715)를 포함한다. 도 6의 단계들(605, 610 및 640)과 관련하여 설명한 바와 같이, 이러한 다이내믹 인스트루먼테이션 캐시는 분석되고 있는 메소드에 대해 식별된 콜가능한 메소드들을 저장할 수 있다. 이러한 콜가능한 메소드는, 도 6의 단계들(615 내지 630)을 수행하지 않으면서, 동일한 메소드의 이후의 분석이 수행되는 경우 캐시로부터 신속하게 식별될 수 있으며, 이에 의해 컴퓨팅 리소스들의 소비를 줄인다. 리소스(715)는 메모리 위치가 될 수 있는데, 이는 어플리케이션이 인스트루먼트되고 실행되기 시작할 때에 메모리 내에 로드되는 그 어플리케이션의 다른 클래스들의 바이트 코드를 저장하는 데에 이용된다. 하나의 가능한 구현에서, 다이내믹 인스트루먼테이션 캐시(702) 및 리소스(715)는 어플리케이션 서버 내의 도 2의 메모리(240) 내에 제공된다.
java.lang.instrument API(710)는, 도 6의 단계들(615 및 617)에 대응하여, 분석되고 있는 적어도 하나의 메소드의 특정 클래스(725)를 결정하기 위해 로드된 모든 클래스들(705)를 액세스하는 데에 이용된다. 하나의 시도에서, 로드된 모든 클래스들은 어레이로 제공된다. 클래스(725)에 기초하여, 클래스 로더(720)는, 도 6의 단계들(620 및 622)에 대응하여, 그 클래스(725)에 대한 클래스 바이트 코드(730)를 로드하기 위해 리소스(715)를 액세스하는 데에 이용된다. 클래스 바이트 코드(730)는, 도 6의 단계들(625 및 627)에 따라, 오피코드들(735, 740, 745 및 750)의 하나 이상의 인스턴스들을 식별하기 위해 파싱된다. 각 오피코드는 각각의 인덱스 바이트들, <indexbyte1, indexbyte2>를 가질 수 있는데, 이들은 도 6의 단계들(630, 632 및 634)에 따라, 상수 풀(755)로부터 메소드 콜의 스트링을 페치하는 데에 이용된다.
도 8은 소프트웨어를 인스트루먼트하기 위한 예시적인 프로세스의 흐름을 도시한다. 도 5A와 대응하게, 컴포넌트들의 스태틱 리스트(810)는 클래스 로더(802)에 제공될 수 있으며, 이러한 클래스 로더는 인스트루먼트되는 바이트 코드를 제공하기 위해 변환기/프로브 빌더(800)에 의해 이용되는 바이트 코드를 로드한다. 이를 테면, 상기 메소드 defineClass는 바이트들의 어레이를 클래스 Class의 인스턴스로 변환한다. 또한, 발견되는 컴포넌트들(806), 이를 테면 도 6의 프로세스에 의해 발견되는 메소드들이 인스트루먼트될 수 있다. 하나의 시도에서, 도 4C 또는 도 9에 도시된 것과 같은 사용자 인터페이스(808)는 사용자로 하여금 인스트루먼트될 발견된 컴포넌트들을 지정할 수 있게 한다. 사용자는 또한 스태틱 리스트(810)를 수정할 수 있다. 이러한 사용자 인터페이스는, 관리되는 어플리케이션 내의 기존의 인스트루먼테이션으로부터 흐르는 성능 데이터를 모니터하는 성능 모니터(812)에 응답하여, 이를 테면 일부 컴포넌트들이 트랜잭션에 문제(실행하는 데에 너무 많은 시간이 든다 등등)를 일으키고 있다는 사실을 식별할 수 있다. 상기 성능 데이터를 더 낮은 임계치 및 더 높은 임계치와 비교하여, 이것이 범위를 벗어나는 지의 여부를 결정할 수 있다.
발견되는 컴포넌트는 인스트루먼트되어야 하는 동적으로 업데이트가능한 클래스들의 리스트를 포함할 수 있다. 이러한 리스트는 종종 달라질 수 있으며, 이에 따라 진단이 수행되는 제한된 시간 기간 동안 특정의 메소드들이 인스트루먼트된다. 사용자 인터페이스(808)가 시간 기간을 특정하거나, 또는 디폴트(default) 시간 기간이 이용될 수 있다. 따라서, 컴포넌트는 재정의(redefine)될 수 있으며, 이에 따라 이는, 예를 들어 하나의 시점에서 인스트루먼테이션을 갖지 않는 것으로부터 다른 시점에서 인스트루먼테이션을 갖는 것으로 천이된다. 또한, 다른 타입들 또는 레벨들의 인스트루먼테이션, 예를 들어 하이 레벨의 인스트루먼테이션(이 경우, 컴포넌트의 성능의 많은 양상들이 추적(track)된다) 및 로우 레벨의 인스트루먼테이션(이 경우, 컴포넌트의 성능의 약간의 양상들 만이 추적된다)을 제공하는 것이 가능하다. 따라서, 컴포넌트를 재정의하는 것은, 다른 타입의 인스트루먼테이션으로의 천이를 수반한다.
인스트루먼테이션은, 컴포넌트의 평균 실행 또는 응답 시간, 초당 또는 간격당 인보케이션 비율(invocation rate), 인보케이션의 카운트, 간격당 시작되었지만 완료되지 않은 인보케이션들의 수를 나타내는 동시발생 메트릭(concurrency metric) 및 그 메소드 인보케이션 횟수가 간격당 특정 임계치를 초과하는 시작된 인보케이션들의 수를 나타내는 정체 메트릭(stalled metric)을 포함하는, 많은 타입의 성능 메트릭/데이터(metrics/data)를 산출할 수 있다. 또한, 데이터는 쓰레기 수집 히프 사이즈(garbage collection heap size), 파일(file) 및 소켓 액티비티(socket activity)를 나타내는 대역폭 메트릭(bandwidth metric), 쓰레드들(threads)의 수, 시스템 로그들(system logs), 예외들, 메모리 리크들(memory leaks) 및 컴포넌트 인터랙션들(component interactions)을 식별할 수 있다. 데이터는 또한, 인스트루먼트되는 컴포넌트에 의해 어떤 컴포넌트들이 콜되는지, 또는 인스트루먼트되는 컴포넌트가 어떤 것을 콜하는 지를 식별할 수 있다. 이를 테면, 제어기 아키텍쳐에 있어서, 제어는 어떤 컴포넌트들이 다음으로 실행되는 지를 제어하는 제어기 컴포넌트를 통해 흐르며, 이들이 얼마나 빈번하게 실행되는지와 이들이 어떻게 수행되는 지를 알고 있다. 이러한 제어기 컴포넌트는, 인스트루먼테이션을 통해, 인스트루먼트되지 않은 어떤 컴포넌트들이 빈번하게 인보크되고 있고, 이에 따라 관심의 대상이며, 인스트루먼테이션을 부가하도록 재정의되어야 하는 지에 대해 보고할 수 있다.
언급된 바와 같이, 인스트루먼테이션의 타입을 변경하기 위해 컴포넌트를 다시 정의하는 것이 가능하다. 예를 들어, 기존 인스트루먼테이션이 문제를 검출할 때(예를 들어, 범위 밖에 존재하는 하나 이상의 파라미터들로 인해), 더 많은 인스트루먼테이션이 부가될 수 있다. 또한, 추가적인 인스트루먼테이션은 실질적으로 제거될 수 있다(인스트루먼테이션이 정상 상태 복귀를 확립하는 경우). 이러한 제거는 사용자 커맨드에 근거하여 혹은 자동으로, 사용자의 개입 없이 수행될 수 있다.
발견된 컴포넌트들(806), 사용자 인터페이스(808), 컴포넌트들의 스태틱 리스트(810), 및 성능 모니터(812)는 동일한 위치에 혹은 서로 다른 위치에 제공될 수 있음에 유의해야 한다. 예를 들어, 사용자 인터페이스(808)는 사용자 인터페이스 호스트(122)(도 1)에 제공될 수 있고, 발견된 컴포넌트들(806) 및 컴포넌트들의 스태틱 리스트(810)는 어플리케이션 서버(106 또는 110)에 제공될 수 있고, 그리고 성능 모니터(812)는 관리자(120)와 관련될 수 있는바, 관리자(120)는 어플리케이션 서버들(106, 110)에서 에이전트들(108 및 112)로부터 각각 성능 데이터를 수신한다.
성능 모니터(812)는, 어떤 컴포넌트들이 문제 트랜잭션에 수반되는지에 관한 아이디어를 제공하고, 그리고 이러한 컴포넌트들이 문제를 일으킬 수 있는지 혹은 일으키고 있는지 여부를 결정할 수 있고, 그리고 사용자 인터페이스(808) 상에서 이러한 정보를 식별할 수 있다.
사용자 인터페이스(808)는 사용자로 하여금, 예를 들어, 어떤 컴포넌트들(발견된 컴포넌트들을 포함함)이 인스트루먼트되어야 하는지 혹은 인스트루먼트되지 말아야 하는지를 수동으로 선별 및 선택할 수 있게 한다. 서로 다른 타입들이 이용가능할 때, 인스트루먼테이션의 타입이 사용자 인터페이스를 통해 특정될 수 있다.
컴포넌트들의 스태틱 리스트(810)는, 어플리케이션이 실행을 시작할 때, 인스트루먼트되어야하는 클래스들 혹은 다른 컴포넌트들을 포함할 수 있다. 이것은 중요한 데이터를 산출할 것으로 예측되는 컴포넌트들의 베이스라인 리스트(baseline list)일 수 있다. 한 가지 접근법으로서, 발견된 컴포넌트들(806)의 리스트는, 다음 시스템 시동시 동일한 컴포넌트들이 인스트루먼트되도록, 유지될 수 있다. 이것은 사용자로 하여금 컴포넌트로부터 일정한 데이터, 보고 및 성능 데이터를 가질 수 있도록 하며, 아울러 사용자로 하여금 환경을 설정할 수 있게 하는 양호한 방식을 제공한다.
컴포넌트가 런타임에서 어플리케이션에 이미 통합되었는지 여부에 따라, 컴포넌트는 서로 다른 방식으로 다시 정의될 수 있다. 만약 컴포넌트가 어플리케이션에 이미 통합된 것이 아니라면, 가능한 일 구현에서, 컴포넌트는, 클래스 로더(class loader)(802)에 의해 예를 들어 JVM에 로딩됨으로써 일반적으로 통합될 수 있다. .NET 프레임워크을 사용하는 것과 같은 다른 구현들에서, 클래스 로더는 사용되지 않는다.
컴포넌트가 로딩될 때, 변환기/프로브 빌더(800)는, 지시받은 경우, 예를 들어, 사용자 인터페이스(808), 발견된 컴포넌트들(806), 컴포넌트의 스태틱 리스트(810) 및 성능 모니터(812)에 응답하여, 컴포넌트를 인스트루먼트한다. 어플리케이션에 이미 통합되었지만 인스트루먼트되지는 않은 컴포넌트는, 인스트루먼테이션으로 어플리케이션에 다시 통합될 수 있다. 예를 들어, 컴포넌트는 어플리케이션으로부터 제거될 수 있고 그리고 가상 머신(virtual machine)을 다시 시작함이 없이 런타임 동안 다시 로딩될 수 있다. 이러한 목적을 달성하기 위해, 자바 redefineClass 커맨드가 컴포넌트를 갖는 클래스 로더(802)에 제공된다. 자바 개발 키드(JAVA DEVELOPMENT KIT, JDK) 버전 1.5 혹은 그 이상은 이러한 커맨드를 사용하는 재정의 능력(redefinition capability)을 갖는다. 이러한 커맨드는 공급된 클래스 파일들을 사용하여 클래스들의 공급된 세트를 다시 정의한다. 이것은 동시에 하나 이상의 클래스로의 인터락된 변경을 가능하게 하기 위해 세트에 관해 동작한다. 더욱이, 만약 재정의된 메소드가 활성 스택 프레임들을 갖는다면, 이러한 활성 프레임들은 본래 메소드의 바이트 코드들을 계속 실행시키고, 그리고 재정의된 메소드는 새로운 인보크들에서 사용될 수 있다.
클래스와 같은 컴포넌트를 다시 정의하는 것은 단지 해당 클래스에 대해서라는 것만 제외하고 가상 머신을 다시 시작시키는 것과 유사하다. 클래스가 다시 정의되는 경우, 만약 클래스가 이미 기존의 메소드 스택에 있다면, 클래스는 거기서 머무른다. 그러나, 매 새로운 메소드 인보케이션에 대해서, 새로운 클래스가 사용된다. 즉, 재정의되는 경우, 새로운 버전이 선택된다.
변환기/프로브 빌더(800)가, 다시 정의된 컴포넌트를 수신하는 경우, 그 컴포넌트를 인스트루먼트한다(만약 그렇게 하도록 지시받았다면). 변환기/프로브 빌더(800)는 또한, 컴포넌트에 특정 타입의 인스트루먼테이션을 부가할 수 있다.
발견된 컴포넌트가 인스트루먼트되었고, 어플리케이션에 다시 통합되었으며, 그리고 인스트루먼테이션이 이제 더 이상 진단을 위해 필요하지 않게 된 이후에, 컴포넌트는 어플리케이션에 재통합될 수 있지만, 인스트루먼테이션이 없이 통합된다. 인스트루먼테이션의 제거는 사용자 커맨드, 특정 진단 기간 혹은 다른 어떤 다른 이벤트 이후의 타임 아웃에 근거를 둘 수 있다. 예를 들어, 성능 모니터(812)는 발견된 컴포넌트의 성능 데이터가 일정 시간 기간에 대해 혹은 컴포넌트의 인보케이션의 수에 대해, 수용가능한지를 결정할 수 있다. 즉, 성능 모니터(812)는 인스트루먼트된 메소드들 중 적어도 하나의 메소드의 성능 데이터가 이제 더 이상 임계 성능 레벨을 충족시키지 못하는지를 결정할 수 있다. 응답으로서, 성능 모니터(812)는 인스트루먼테이션을 제거하기 위해 redefineClass와 같은 커맨드를 발행할 수 있다.
인스트루먼테이션의 부가 및 제거가 런타임에서 동적으로 수행될 수 있고, 이에 따라 바이트 코드가 실행되는 가상 머신의 레벨이 낮추어질 필요가 없으며, 그리고 인스트루먼트된 컴포넌트들로부터의 데이터가 즉각적으로 액세스될 수 있다(인스트루먼테이션 부가의 경우에).
도 9는 컴포넌트들 및 대응하는 성능 데이터 간의 계층적 관계를 나타내는 사용자 인터페이스 디스플레이를 도시하고, 여기서 사용자는 인스트루먼트될 컴포넌트를 수동으로 식별할 수 있다. 사용자 인터페이스(900)는, 분석되는 메소드의 콜가능 컴포넌트들로서 발견되었던 하나 이상의 컴포넌트들의 명칭을 식별하는 디스플레이 영역(902)을 포함한다. 다른 컴포넌트들의 명칭들이 또한 제공될 수 있다. 본 예에서, C5A는 단독으로 발견된 컴포넌트이다. 컴포넌트에 대한 인스트루먼테이션을 선택하기 위해, 사용자는 컴포넌트 명칭/식별자 옆의 체크박스를 체크할 수 있다. 또는 인스트루먼테이션이 컴포넌트에 자동으로 적용될 수 있다. 디스플레이 영역(902)은 또한, 사용자가 디스플레이 영역(904)에서 하나 이상의 컴포넌트들을 선택하여, 인스트루먼테이션에 근거한 그 컴포넌트에 대한 데이터(예를 들어, 트레이스(trace))를 디스플레이 영역(906)에 디스플레이할 수 있음을 사용자에게 알려준다.
유사하게, 사용자는 인스트루먼테이션이 컴포넌트로부터 제거돼야함을 표시하기 위해 체크박스를 체크해제할 수 있다. 서로 다른 타입의 인스트루먼테이션을 특정하기 위해, 추가적인 체크박스들 혹은 다른 사용자 인터페이스 기술들이 사용될 수 있다. 더욱이, 사용자가 사용자 인터페이스(900)를 처음 볼 때, 체크박스들은, 이들의 현재 인스트루먼테이션 상태에 따라, 사전에 체크되어 있거나 혹은 체크해제되어 있을 수 있다. 일부 경우에 있어서, 체크박스는, 예를 들어, 인스트루먼테이션이 임계적 컴포넌트들로부터 비의도적으로 제거되지 않도록, 컴포넌트의 인스트루먼테이션 상태가 변경될 수 없음을 표시하기 위해 그레이아웃(gray out)처리 될 수 있다.
사용자는, 예를 들어 문제해결을 경험하기 전에 어떤 컴포넌트들이 에러에 관련되어 있는지 혹은 자체적으로 에러를 발생시키고 있는지 및 다른 요인들에 관한 관측에 근거하여 어떤 발견된 컴포넌트들에 인스트루먼테이션이 부가돼야만 함을 표시할 수 있다.
디스플레이 영역(904)은 트리(tree)와 같은 계층적 구조를 사용하여 어플리케이션에서의 컴포넌트들 각각으로 자동으로 채워질 수 있다(여기서 트리는 어떤 컴포넌트가 또 다른 컴포넌트 아래에 있는지 혹은 또 다른 컴포넌트에 의해 콜되는지를 보여줌). 디스플레이 영역(906)은, 영역(904)에서의 컴포넌트들 중 선택된 것들에 대해, 인스트루먼테이션에 근거한 인스트루먼트된 컴포넌트들의 트랜잭션 트레이스와 같은 성능 데이터를 도시한다. 예를 들어, 컴포넌트 명칭 아래에 밑줄에 의해 표시된 바와 같이, 컴포넌트들(C1, C5 및 C5A)이 현재 사용자에 의해 선택되었고, 트랜잭션 트레이스와 같은 대응하는 성능 데이터가 영역(906) 내에 곡선(910, 912 및 914)에 의해 제공된다. 영역(906)은 에이전트로부터 중앙 관리자로 제공되는 성능 데이터로 채워질 수 있다.
일부 접근법들에서, 영역(904)에서의 디스플레이되는 정보는, 단지 발견된 컴포넌트들만이 디스플레이되도록 필터링될 수 있다. 더욱이, 사용자는 노드의 하위 레벨 컴포넌트들을 보기 위해 트리의 노드들을 전개할 수 있다.
도 10은 도 6의 단계(600)의 더 상세한 내용을 제공한다. 분석을 위한 어플리케이션에서의 적어도 하나의 메소드의 식별은 다양한 인자들에 근거할 수 있다. 한가지 가능한 접근법으로, 성능 데이터에 근거하여 적어도 하나의 메소드가 식별된다. 특히, 단계(1000)는 어플리케이션에서의 메소드들을 인스트루먼트하는 것을 포함한다. 예를 들어, 이것은 도 5a 및 도 5b와 연계되어 설명된 바와 같은 스태틱 인스트루먼테이션을 포함할 수 있다. 단계(1005)는 인스트루먼트된 메소드들로부터 성능 데이터를 획득하는 것을 포함한다. 성능 데이터는, 도 4a 내지 도 4c 및 도 9에 도시된 바와 같이, 실시간 업데이트를 통해, 지속적으로 획득될 수 있고 아울러 사용자 인터페이스 상에 디스플레이될 수 있다. 막대 그래프, 그래프, 도표 등과 같은 다양한 다른 디스플레이들이 또한 제공될 수 있다. 단계(1010)는 인스트루먼트된 메소드들 중 적어도 하나의 메소드의 성능 데이터가 임계 성능 레벨 아래로 떨어지는 지를 결정하는 것을 포함한다. 예를 들어, 도 4a에서, 성능 데이터는 C5(442)의 응답 시간(t16-t11)을 포함할 수 있다. 이러한 시간(예를 들어, 5개의 시간 단위들)이 너무 길고, (응답 시간이 4개 이하의 시간 단위들일 것을 요구하는) 임계 성능 레벨을 초과한다고 가정한다. 따라서, 컴포넌트 혹은 메소드 C5는 분석할 적어도 하나의 메소드로서 식별될 수 있다. 실제로, 서로 다른 많은 메소드들의 성능 데이터는, 이들이 예측된 범위 내에 있는지를 보증하기 위해 임계 레벨들에 대비되어 계속 평가될 수 있고, 그리고 예측된 범위 내에 있지 않은 메소드들은 분석을 위해 플래그(flag)될 수 있다. 단계(1015)는, 도 6의 단계들(605 내지 640)의 프로세스와 같은, 적어도 하나의 메소드에서 콜가능한 하나 이상의 메소드들을 식별 및/또는 인스트루먼트하기 위한 프로세스를 트리거한다.
도 11은, 하나 이상의 참조 메소드들을 보고 및/또는 인스트루먼트하는 것에 관한, 도 6의 단계(640)의 더 상세한 내용을 제공한다. 단계(1100)는 하나 이상의 참조 메소드들, 즉 분석되는 적어도 하나의 메소드에 의해 콜가능한 메소드들을 보고하는 것을 포함한다. 보고는 예를 들어, 도 4c에 제시된 바와 같이, 사용자 인터페이스 디스플레이 형태일 수 있다. 도 4c에서, 하나 이상의 참조 메소드들은 새롭게 발견된 컴포넌트 C5A를 포함한다. 단계(1105)는 하나 이상의 참조 메소드들을 인스트루먼트하는 것을 포함한다. 이것은 예를 들어, 도 8의 기술을 포함할 수 있다. 인스트루먼테이션은, 예를 들어, 어플리케이션의 런타임 동안 인스트루먼테이션이 일어날 수 있도록 동적일 수 있으며, 그리고 예를 들어, 어플리케이션이 사용자로부터 원격 위치에 있는 경우처럼 원격으로 일어날 수 있다.
단계(1110)는 하나 이상의 인스트루먼트된 메소드들로 어플리케이션을 실행시키는 것을 포함한다. 실제로, 어플리케이션은 부가된 인스트루먼테이션을 갖는 하나 이상의 참조 메소드들로 계속 실행될 수 있다. 단계(1115)는 하나 이상의 인스트루먼트된 메소드들에 대해 성능 데이터를 획득하는 것을 포함한다. 따라서, 인스트루먼테이션의 추가로 인해, 하나 이상의 발견된 메소드들에 관한 성능 데이터가 이제 획득될 수 있다. 이것은 메소드와 관련된 문제를 진단함에 있어 특히 유용할 수 있다. 단계(1120)는 성능 데이터를 평가하는 것을 포함한다. 이것은, 예를 들어, 성능 데이터를 허용가능한 범위의 값들과 비교함으로써 아울러 만약 성능 데이터가 범위를 벗어나는 경우 혹은 그렇지 않으면 최저 레벨 아래 또는 최고 레벨 위에 있는 경우 플래그를 설정함으로써, 자동으로 수행될 수 있다. 단계(1125)는, 도 13에서 설명된 바와 같은, 하나 이상의 인스트루먼트된 메소드들에 의해 콜가능한 하나 이상의 메소드들을 식별 및/또는 인스트루먼트하기 위한 프로세스를 트리거하는 것을 포함한다. 즉, 반복 기술이 수행될 수 있는바, 여기서는, 분석되는 본래 메소드 아래의 일 레벨(차일드 메소드(child method))까지의 드릴 다운(drill down)이 존재한다. 후속적으로, 만약 차일드 메소드의 성능 데이터에 의해 보증되는 경우, 혹은 다른 이유로 인해, 드릴 다운은 분석되는 본래 메소드 아래의 두 레벨(그랜드차일드 메소드(grandchild method), 혹은 이전 차일드 메소드의 차일드)까지 수행될 수 있다. 프로세스는, 메소드들의 계층에서 하위 레벨 메소드를 연속적으로 분석하기 위해 반복될 수 있다.
또 다른 하나의 가능한 접근법에서, 초기 드릴 다운은, 예를 들어, 분석되는 본래 메소드 아래의 두 레벨 이상(차일드 메소드와 그랜드차일드 메소드 양쪽 모두)까지 이루어질 수 있다. 인스트루먼테이션은 차일드 메소드와 그랜드차일드 메소드 양쪽 모두에 동시에 부가될 수 있다. 이러한 인스트루먼테이션으로부터의 성능 데이터는 추가의 레벨까지의 드릴 다운 및 추가의 레벨의 인스트루먼테이션이 보증되는지 여부를 표시할 수 있다.
도 12는 하나 이상의 참조 메소드들을 보고 및/또는 인스트루먼트하는 것에 관한, 도 6의 단계(640)의 더 상세한 내용을 제공한다. 단계(1200)는, 하나 이상의 참조 메소드들을 표시하는 규칙이 설정되었는지, 즉 분석되는 적어도 하나의 메소드에 의해 콜가능한 새롭게 발견된 메소드들이 인스트루먼트되어서는 안 되는지를 결정한다. 일부 경우에 있어, 도 5a 및 도 5b의 규칙들(505 및 555)은 어떤 메소드들이 인스트루먼트되어서는 안 된다는 것을 표시할 수 있다. 이러한 것은, 예를 들어, 메소드가 네이티브이며 따라서 바이트 코드를 가지지 않는 경우, 메소드가 속한 클래스가 자바 API에 의해 변환가능하지 않는 것으로 마킹되는 경우, 또는 메소드/클래스가 에이전트 프로브 빌더 지시어(Probe Builder Directive, PBD) 인스트루먼테이션에 의해 "생략된"으로서 마킹되고 이것을 취소하기를 원하지 않는 경우에 일어날 수 있다.
하나 이상의 참조 메소드들이 인스트루먼트되어서는 안 된다고 규칙이 표시함을 나타내는 보고가, 사용자 인터페이스를 통해 만들어질 수 있다. 단계(1205)는 하나 이상의 참조 메소드들이 이미 인스트루먼트되었는지 여부를 결정하는 것을 포함한다. 예를 들어, 일부 경우에 있어서, 메소드는 활성화되지 않은 인스트루먼테이션을 가질 수 있고, 이러한 경우에 인스트루먼테이션을 활성화시키는 것이 가능하다. 또한, 메소드가 이미 인스트루먼트되었음을 사용자에게 디스플레이하기 원할 수 있고, 따라서 만약 트랜잭션 컴포넌트들에서 이에 관한 어떠한 정보도 알 수 없다면, 이는 콜되지 않기 때문이다. 단계(1210)는 하나 이상의 참조 메소드들이 인터페이스 클래스에 있는지 여부를 결정하는 것을 포함한다. 사용자 인터페이스는 이러한 사실을 보고할 수 있고, 그리고 사용자로 하여금, 하나 이상의 참조 메소드들이 인스트루먼트되어야 하는지 여부를 표시하기 위한 커맨드를 제공하도록 할 수 있다. 이러한 경우에, 인스트루먼테이션은 모든 구현 클래스들을 인스트루먼트하는 것을 포함한다. 이것은 일부 경우에 있어 바람직하지 않을 수 있는 상당량의 인스트루먼테이션일 수 있다.
단계들(1200 내지 1210)의 정보는, 가능한 메소드 콜들 각각에 대한 반사를 사용하여 에이전트에 의해 제공될 수 있다. 이러한 정보는 콜가능한 메소드들에 인스트루먼테이션을 부가할지 여부를 결정함에 있어 사용자를 지원할 수 있다. 이러한 정보는, 예를 들어, 자바 5 인스트루먼트 API에 의해 제공되는, 로딩된 클래스들의 어레이로부터 검색된 클래스 상의 반사를 통해 획득될 수 있다. 이러한 정보는, 정보를 다시 결정함에 있어 연산 자원들이 소비되는 것을 피하기 위해, 후속 액세스를 위해 캐시될 수 있다.
도 13은 도 11의 단계(1125)의 더 상세한 내용을 제공한다. 도 13의 프로세스는 도 6의 프로세스와 유사하지만, 하나 이상의 차일드 메소드들의 관점에서 설명된다. 단계(1300)는 하나 이상의 참조 메소드들이 적어도 하나의 메소드(예를 들어, 도 6의 단계(600)에서 분석할 적어도 하나의 메소드)의 하나 이상의 차일드 메소드들임을 표시한다. 단계(1305)는 도 6의 단계(615)와 유사하며, 하나 이상의 차일드 메소드들의 클래스를 결정한다. 단계(1310)는 도 6의 단계(620)와 유사하며, 예를 들어, 바이트 코드가 획득되는 본래 자원 위치로부터, 하나 이상의 차일드 메소드들의 클래스의 바이트 코드 표현을 로딩하는 것을 포함한다. 단계(1315)는 도 6의 단계(625)와 유사하며, 인보크 바이트 코드의 하나 이상의 인스턴스들을 식별하기 위해 단계(1305)에서 획득된 각각의 클래스의 바이트 코드 표현을 파싱하는 것을 포함한다. 단계(1320)는 도 6의 단계(630)와 유사하며, 하나 이상의 차일드 메소드들의 (단계(1315)의) 인보크 바이트 코드의 하나 이상의 인스턴스들에 근거하여, 하나 이상의 차일드 메소드들의 하나 이상의 그랜드차일드 참조 메소드를 식별한다. 단계(1325)는 도 6의 단계(635)와 유사하며, 하나 이상의 그랜드차일드 참조 메소드들을 캐시 내에 스트링으로서 저장한다. 단계(1330)는 도 6의 단계(640)와 유사하며, 하나 이상의 그랜드차일드 참조 메소드들을 보고 및/또는 인스트루먼트하는 것을 포함한다.
도 14는 도 6의 단계(640)의 더 상세한 내용을 제공한다. 도 1과 연계되어 설명된 바와 같이, 복수의 어플리케이션 서버들은 중앙 관리자와 통신하는 각각의 에이전트들을 가질 수 있다. 따라서, 에이전트들은, 어플리케이션과 같은 동일한 코드의 개별 인스턴스들을 포함하는 어플리케이션 서버들을 실행시키고 있는, JVM들의 클러스터(cluster)에 배치될 수 있다. 에이전트 A1(108)과 같은 하나의 에이전트가 어플리케이션에서의 적어도 하나의 메소드를 분석하고, 그리고 하나 이상의 참조 메소드들을 결정할 때, 하나 이상의 참조 메소드들의 식별이, 예를 들어, 관리자(120)를 통해, 하나 이상의 에이전트들과 공유될 수 있다. 예를 들어, 에이전트 A1(108)는, 메소드 콜들의 새로운 세트, 예를 들어, 콜가능 메소드들이 소정의 클래스 및 메소드에 대해 검색되었다고 관리자(120)에게 신호를 보낼 수 있다. 관리자(120)는 그 다음에 클러스터 내의 관심의 대상일 수 있는 다른 에이전트(예를 들어, 에이전트 A2(112))로 정보를 푸시(push)할 것을 결정할 수 있다. 이것은 다른 에이전트들에 관한 메소드 콜 검출 단계들의 불필요한 반복을 피할 수 있고, 그리고 에이전트들로 하여금, 발견된 콜가능 메소드들의 서로 다른 인스턴스들로부터 성능 데이터를 수집할 수 있게 한다. 어플리케이션의 서로 다른 인스턴스들에 걸쳐 동일한 메소드에 대한 성능 데이터를 관측함으로써, 어플리케이션의 연산에 대해 더 큰 통찰력이 획득될 수 있다.
예시적 프로세스에서, 단계(1400)는, 어플리케이션의 제 1 인스턴스와 관련된 제 1 에이전트(108)로부터 관리자에게 하나 이상의 참조 메소드들을 보고한다. 단계(1405)에서, 관리자는, 어플리케이션의 하나 이상의 다른 인스턴스들과 관련된 하나 이상의 다른 에이전트들(112)에 하나 이상의 참조 메소드들의 식별을 푸시한다. 단계(1410)에서, 하나 이상의 다른 에이전트들은, 어플리케이션의 하나 이상의 다른 인스턴스들에서의 하나 이상의 참조 메소드들의 하나 이상의 다른 인스턴스들을 인스트루먼트한다.
전술한 본 발명의 상세한 설명은 예시 및 설명 목적으로 제공되었다. 이러한 것이 본 발명의 모두를 설명하도록 의도되지 않았으며 혹은 본 발명이 이렇게 개시되는 특정 형태로만 한정되도록 의도되지도 않았다. 많은 수정 및 변형이 앞서의 가르침을 고려하는 경우 가능하다. 본 명세서에서 설명되는 실시예들은 본 발명의 원리 및 그 실제 응용을 가장 잘 설명하기 위해 선택되었는 바, 이로 인해 본 발명의 기술 분야에서 숙련된 기술을 가진 다른 사람들이 다양한 실시예로 그리고 고려하는 특정 용도에 적합하도록 다양하게 수정하여 본 발명을 가장 잘 사용할 수 있도록 하기 위한 것이다. 본 발명의 범위는 본 명세서에 첨부되는 특허청구범위에 의해 정의되도록 의도되었다.

Claims (17)

  1. 컴퓨터에 의해 수행되는, 어플리케이션을 분석하는 방법으로서,
    상기 어플리케이션에서 분석을 하기 위한 메소드를 식별하는 단계와;
    메모리에 로딩된 클래스들 중에서 상기 분석을 하기 위한 메소드의 클래스를 결정하는 단계와;
    리소스 위치로부터 상기 분석을 하기 위한 메소드의 클래스의 바이트 코드 리프리젠테이션을 로딩하는 단계와;
    상기 분석을 하기 위한 메소드의 클래스의 바이트 코드 리프리젠테이션을 파싱하는 단계 - 상기 파싱하는 단계는 상기 분석을 하기 위한 메소드의 클래스의 바이트 코드 리프리젠테이션 내의 인보크(invoke) 바이트 코드의 인스턴스를 식별함 - 와;
    상기 분석을 하기 위한 메소드의 클래스의 바이트 코드 리프리젠테이션 내의 인보크 바이트 코드의 인스턴스에 기초하여, 상기 분석을 하기 위한 메소드의 차일드 참조 메소드(child referenced method)를 식별하는 단계와;
    상기 차일드 참조 메소드를 스트링으로서 저장하는 단계와;
    리소스 위치로부터 상기 차일드 참조 메소드의 클래스의 바이트 코드 리프리젠테이션을 로딩하는 단계와;
    상기 차일드 참조 메소드의 클래스의 바이트 코드 리프리젠테이션 내의 인보크 바이트 코드의 인스턴스를 식별하기 위해 상기 차일드 참조 메소드의 클래스의 바이트 코드 리프리젠테이션을 파싱하는 단계와;
    상기 차일드 참조 메소드의 클래스의 바이트 코드 리프리젠테이션 내의 인보크 바이트 코드의 인스턴스에 기초하여, 상기 분석을 하기 위한 메소드의 그랜드차일드 참조 메소드(grandchild referenced method)를 식별하는 단계와; 그리고
    상기 그랜드차일드 참조 메소드를 스트링으로서 저장하는 단계를 포함하는 어플리케이션을 분석하는 방법.
  2. 제 1항에 있어서,
    상기 분석을 하기 위한 메소드 및 상기 차일드 참조 메소드 중 적어도 하나에 대해, 상기 인보크 바이트 코드는 invokevirtual, invokespecial, invokestatic 및 invokeinterface 중 하나 이상을 포함하는 것을 특징으로 하는 어플리케이션을 분석하는 방법.
  3. 제 1항 또는 2항에 있어서,
    상기 차일드 참조 메소드를 스트링으로서 저장한 후, 상기 어플리케이션에서 상기 차일드 참조 메소드를 인스트루먼트(instrument)하는 단계; 또는
    상기 그랜드차일드 참조 메소드를 스트링으로서 저장한 후, 상기 어플리케이션에서 상기 그랜드차일드 참조 메소드를 인스트루먼트하는 단계; 또는
    상기 차일드 참조 메소드를 스트링으로서 저장한 후, 상기 어플리케이션에서 상기 차일드 참조 메소드를 인스트루먼트하는 단계 그리고 상기 그랜드차일드 참조 메소드를 스트링으로서 저장한 후, 상기 어플리케이션에서 상기 그랜드차일드 참조 메소드를 인스트루먼트하는 단계를 더 포함하는 것을 특징으로 하는 어플리케이션을 분석하는 방법.
  4. 제 1항 또는 2항에 있어서,
    상기 분석을 하기 위한 메소드 및 상기 차일드 참조 메소드 중 적어도 하나에 대해, 상기 인보크 바이트 코드의 인스턴스는 상기 클래스의 상기 바이트 코드 리프리젠테이션에 있는 오피코드(opcode)로부터 식별되고;
    상기 오피코드는 상수 풀 테이블(constant pool table)에 있는 엔트리에 대한 인덱스와 관련되고; 그리고
    상기 참조 메소드는 상기 인덱스를 이용하는 것을 특징으로 하는 어플리케이션을 분석하는 방법.
  5. 제 1항 또는 2항에 있어서,
    상기 분석을 하기 위한 메소드 및 상기 차일드 참조 메소드 중 적어도 하나에 대해, 상기 클래스는 JAVA Instrument API를 이용하여 판단되고 상기 로딩은 JAVA 클래스 ClassLoader를 이용하는 것을 특징으로 하는 어플리케이션을 분석하는 방법.
  6. 제 1항 또는 2항에 있어서,
    상기 분석을 하기 위한 메소드는 상기 어플리케이션 내의 메소드들 - 상기 어플리케이션 내의 메소드들은 상기 분석을 하기 위한 메소드를 포함함 - 을 인스트루먼트하고 상기 인스트루먼트로부터 획득된 성능 데이터를 분석함으로써 식별되는 것을 특징으로 하는 어플리케이션을 분석하는 방법.
  7. 제 1항 또는 2항에 있어서,
    상기 차일드 참조 메소드를 스트링으로서 저장한 후, 상기 차일드 참조 메소드에 인스트루먼테이션을 추가할지 여부를 결정하는 것을 지원하기 위해 JAVA Reflection API를 이용하여 정보를 제공하는 단계; 또는
    상기 그랜드차일드 참조 메소드를 스트링으로서 저장한 후, 상기 그랜드차일드 참조 메소드에 인스트루먼테이션을 추가할지 여부를 결정하는 것을 지원하기 위해 JAVA Reflection API를 이용하여 정보를 제공하는 단계; 또는
    상기 차일드 참조 메소드를 스트링으로서 저장한 후, 상기 차일드 참조 메소드에 인스트루먼테이션을 추가할지 여부를 결정하는 것을 지원하기 위해 JAVA Reflection API를 이용하여 정보를 제공하는 단계 그리고 상기 그랜드차일드 참조 메소드를 스트링으로서 저장한 후, 상기 그랜드차일드 참조 메소드에 인스트루먼테이션을 추가할지 여부를 결정하는 것을 지원하기 위해 JAVA Reflection API를 이용하여 정보를 제공하는 단계를 더 포함하는 것을 특징으로 하는 어플리케이션을 분석하는 방법.
  8. 제 1항 또는 2항에 있어서,
    상기 차일드 참조 메소드를 스트링으로서 저장한 후, 상기 차일드 참조 메소드를 제 1 어플리케이션 서버로부터 중앙 관리자에 보고하는 단계 - 상기 중앙 관리자는, 상기 어플리케이션의 다른 인스턴스에 있는 상기 차일드 참조 메소드의 다른 인스턴스를 인스트루먼트하는데 있어 제 2 어플리케이션 서버에 의한 이용을 위해 상기 차일드 참조 메소드의 식별을 상기 제 2 어플리케이션 서버에 있는 어플리케이션의 다른 인스턴스에 푸시함 - ; 또는
    상기 그랜드차일드 참조 메소드를 스트링으로서 저장한 후, 상기 그랜드차일드 참조 메소드를 제 1 어플리케이션 서버로부터 중앙 관리자에 보고하는 단계 - 상기 중앙 관리자는, 상기 어플리케이션의 다른 인스턴스에 있는 상기 그랜드차일드 참조 메소드의 다른 인스턴스를 인스트루먼트하는데 있어 상기 제 2 어플리케이션 서버에 의한 이용을 위해 상기 그랜드차일드 참조 메소드의 식별을 상기 제 2 어플리케이션 서버에 있는 어플리케이션의 다른 인스턴스에 푸시함 - ; 또는
    상기 차일드 참조 메소드를 스트링으로서 저장한 후, 상기 차일드 참조 메소드를 제 1 어플리케이션 서버로부터 중앙 관리자에 보고하는 단계 그리고 상기 그랜드차일드 참조 메소드를 스트링으로서 저장한 후, 상기 그랜드차일드 참조 메소드를 제 1 어플리케이션 서버로부터 중앙 관리자에 보고하는 단계를 포함하고, 상기 중앙 관리자는, 상기 어플리케이션의 다른 인스턴스에 있는 상기 차일드 참조 메소드 및 상기 그랜드차일드 참조 메소드의 다른 인스턴스를 인스트루먼트하는데 있어 상기 제 2 어플리케이션 서버에 의한 이용을 위해 상기 차일드 참조 메소드 및 상기 그랜드차일드 참조 메소드의 식별을 상기 제 2 어플리케이션 서버에 있는 어플리케이션의 다른 인스턴스에 푸시하는 것을 특징으로 하는 것을 특징으로 하는 어플리케이션을 분석하는 방법.
  9. 어플리케이션을 분석하는 시스템으로서,
    명령어들을 저장하는 프로세서 판독가능 저장 디바이스와; 그리고
    프로세서를 포함하며, 상기 프로세서는 상기 명령어들을 실행하여:
    메모리 내의 상기 어플리케이션의 로딩된 클래스들 중에서 상기 어플리케이션의 메소드의 클래스를 결정하고;
    리소스 위치로부터 상기 클래스의 바이트 코드 리프리젠테이션을 로딩하고;
    인보크 바이트 코드의 인스턴스를 식별하기 위해 상기 클래스의 상기 바이트 코드 리프리젠테이션을 파싱하고;
    상기 인보크 바이트 코드의 인스턴스에 기초하여, 참조 메소드를 식별하고;
    상기 참조 메소드를 스트링으로서 저장하고; 그리고
    상기 참조 메소드에 인스트루먼테이션을 추가할지 여부를 결정하는 것을 지원하기 위한 정보를 제공하도록 구성되며, 상기 정보는 상기 참조 메소드가 인스트루먼트되지 않아야 하는지의 여부, 상기 참조 메소드가 이미 인스트루먼트된지의 여부, 및 상기 참조 메소드가 인터페이스를 참조하는지의 여부 중 적어도 하나를 나타내는 것을 특징으로 하는 어플리케이션을 분석하는 시스템.
  10. 제 9항에 있어서,
    상기 인보크 바이트 코드의 인스턴스는 상기 클래스의 상기 바이트 코드 리프리젠테이션에 있는 오피코드로부터 식별되고;
    상기 오피코드는 상수 풀 테이블에 있는 엔트리에 대한 인덱스와 관련되고; 그리고
    상기 참조 메소드는 상기 인덱스를 이용하는 것을 특징으로 하는 어플리케이션을 분석하는 시스템.
  11. 삭제
  12. 삭제
  13. 삭제
  14. 삭제
  15. 삭제
  16. 삭제
  17. 삭제
KR1020110044254A 2010-05-11 2011-05-11 동적 인스트루먼테이션을 통한 커스텀 코드의 진단을 스트림라인하기위한 메소드 콜의 검출 KR101705265B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/777,496 US8566800B2 (en) 2010-05-11 2010-05-11 Detection of method calls to streamline diagnosis of custom code through dynamic instrumentation
US12/777,496 2010-05-11

Publications (2)

Publication Number Publication Date
KR20110124733A KR20110124733A (ko) 2011-11-17
KR101705265B1 true KR101705265B1 (ko) 2017-02-22

Family

ID=44475086

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020110044254A KR101705265B1 (ko) 2010-05-11 2011-05-11 동적 인스트루먼테이션을 통한 커스텀 코드의 진단을 스트림라인하기위한 메소드 콜의 검출

Country Status (4)

Country Link
US (1) US8566800B2 (ko)
EP (1) EP2386955B1 (ko)
JP (1) JP5798372B2 (ko)
KR (1) KR101705265B1 (ko)

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8732670B1 (en) 2010-06-29 2014-05-20 Ca, Inc. Ensuring determinism during programmatic replay in a virtual machine
US8667472B1 (en) * 2010-07-29 2014-03-04 Disney Enterprises, Inc. System and method of instrumenting code for in-production monitoring
US8745598B2 (en) * 2010-12-14 2014-06-03 Bmc Software, Inc. Running injected code prior to execution of an application
US9116717B2 (en) * 2011-05-27 2015-08-25 Cylance Inc. Run-time interception of software methods
US9430238B2 (en) 2012-03-16 2016-08-30 International Business Machines Corporation Run-time-instrumentation controls emit instruction
US9367316B2 (en) 2012-03-16 2016-06-14 International Business Machines Corporation Run-time instrumentation indirect sampling by instruction operation code
US9471315B2 (en) 2012-03-16 2016-10-18 International Business Machines Corporation Run-time instrumentation reporting
US9411591B2 (en) 2012-03-16 2016-08-09 International Business Machines Corporation Run-time instrumentation sampling in transactional-execution mode
US9442824B2 (en) 2012-03-16 2016-09-13 International Business Machines Corporation Transformation of a program-event-recording event into a run-time instrumentation event
US9465716B2 (en) 2012-03-16 2016-10-11 International Business Machines Corporation Run-time instrumentation directed sampling
US9483268B2 (en) 2012-03-16 2016-11-01 International Business Machines Corporation Hardware based run-time instrumentation facility for managed run-times
US9405541B2 (en) 2012-03-16 2016-08-02 International Business Machines Corporation Run-time instrumentation indirect sampling by address
US9158660B2 (en) 2012-03-16 2015-10-13 International Business Machines Corporation Controlling operation of a run-time instrumentation facility
US9454462B2 (en) 2012-03-16 2016-09-27 International Business Machines Corporation Run-time instrumentation monitoring for processor characteristic changes
US9280447B2 (en) 2012-03-16 2016-03-08 International Business Machines Corporation Modifying run-time-instrumentation controls from a lesser-privileged state
US9250902B2 (en) 2012-03-16 2016-02-02 International Business Machines Corporation Determining the status of run-time-instrumentation controls
US9524225B2 (en) * 2012-03-26 2016-12-20 Microsoft Technology Licensing, Llc Dynamically providing application analytic information
US20150248343A1 (en) * 2012-07-27 2015-09-03 Freescale Semiconductor, Inc. Method and apparatus for implementing instrumentation code
GB2504496A (en) * 2012-07-31 2014-02-05 Ibm Removing code instrumentation based on the comparison between collected performance data and a threshold
US8910127B2 (en) * 2012-09-20 2014-12-09 Identify Software Ltd. (IL) Estimating indirect interface implementation before load time based on directly implemented methods
US8954546B2 (en) 2013-01-25 2015-02-10 Concurix Corporation Tracing with a workload distributor
US9207969B2 (en) 2013-01-25 2015-12-08 Microsoft Technology Licensing, Llc Parallel tracing for performance and detail
US9021262B2 (en) 2013-01-25 2015-04-28 Concurix Corporation Obfuscating trace data
US8924941B2 (en) 2013-02-12 2014-12-30 Concurix Corporation Optimization analysis using similar frequencies
US8997063B2 (en) 2013-02-12 2015-03-31 Concurix Corporation Periodicity optimization in an automated tracing system
US20130283281A1 (en) 2013-02-12 2013-10-24 Concurix Corporation Deploying Trace Objectives using Cost Analyses
US9223681B2 (en) 2013-02-15 2015-12-29 International Business Machines Corporation Automated debug trace specification
US9021448B1 (en) 2013-02-28 2015-04-28 Ca, Inc. Automated pattern detection in software for optimal instrumentation
US9665474B2 (en) 2013-03-15 2017-05-30 Microsoft Technology Licensing, Llc Relationships derived from trace data
US9575874B2 (en) 2013-04-20 2017-02-21 Microsoft Technology Licensing, Llc Error list and bug report analysis for configuring an application tracer
US9292415B2 (en) 2013-09-04 2016-03-22 Microsoft Technology Licensing, Llc Module specific tracing in a shared module environment
RU2570897C2 (ru) * 2013-10-25 2015-12-20 Федеральное государственное бюджетное учреждение науки Институт проблем управления им. В.А. Трапезникова Российской академии наук Способ генерирования переменной эдс при возвратно-поступательном движении
US9772927B2 (en) 2013-11-13 2017-09-26 Microsoft Technology Licensing, Llc User interface for selecting tracing origins for aggregating classes of trace data
JP6295801B2 (ja) * 2014-04-18 2018-03-20 富士通株式会社 分析方法、分析装置、及び分析プログラム
US20150378756A1 (en) * 2014-06-25 2015-12-31 SmartBear Software, Inc. Systems and methods for mobile application tracing instrumentation
US10116512B2 (en) 2014-07-10 2018-10-30 Oracle International Corporation Service discovery and/or effort estimation in networked computing environments
US9594662B2 (en) * 2014-08-27 2017-03-14 Ca, Inc. Automated instrumentation of applications
US10310962B2 (en) * 2014-09-24 2019-06-04 Entit Software Llc Infrastructure rule generation
GB2530527A (en) 2014-09-25 2016-03-30 Ibm A method for controlling a byte code transformer on detection of completion of an asynchronous command
JP6548379B2 (ja) * 2014-10-23 2019-07-24 キヤノン株式会社 情報処理装置およびその制御方法、並びにプログラム
US10042735B2 (en) * 2015-07-10 2018-08-07 Ca, Inc. Selecting application wrapper logic components for wrapping a mobile application based on wrapper performance feedback from user electronic devices
US9588873B1 (en) 2015-09-28 2017-03-07 International Business Machines Corporation Using core files to develop diagnostic programs
US9836320B2 (en) 2016-03-11 2017-12-05 International Business Machines Corporation Collecting performance metrics from java virtual machines
US11151604B2 (en) * 2016-06-10 2021-10-19 International Business Machines Corporation Revenue management using dynamic customer selection
US10749782B2 (en) * 2016-09-10 2020-08-18 Splunk Inc. Analyzing servers based on data streams generated by instrumented software executing on the servers
US10289520B2 (en) 2017-06-23 2019-05-14 New Relic, Inc. Adaptive application performance analysis
JP7293975B2 (ja) 2019-08-20 2023-06-20 株式会社リコー 情報処理装置、情報処理方法、及びプログラム
CN111124931B (zh) * 2019-12-30 2023-10-10 中国农业银行股份有限公司 一种Java代码合规性检查方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7047521B2 (en) 2001-06-07 2006-05-16 Lynoxworks, Inc. Dynamic instrumentation event trace system and methods
JP2006260588A (ja) 1998-08-17 2006-09-28 Microsoft Corp 分散コンポーネントアプリケーションでの待機メソッド呼び出し方法
US20080288212A1 (en) 2007-05-15 2008-11-20 Bernd Greifeneder Method and system for processing application performance data ouside of monitored applications to limit overhead caused by monitoring
US20090254889A1 (en) 2008-04-03 2009-10-08 International Business Machines Corporation Just-in-time dynamic instrumentation

Family Cites Families (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5515536A (en) 1992-11-13 1996-05-07 Microsoft Corporation Method and system for invoking methods of an object through a dispatching interface
US6314558B1 (en) 1996-08-27 2001-11-06 Compuware Corporation Byte code instrumentation
CA2255042C (en) 1998-11-30 2004-04-13 Leonard W. Theivendra Class loader
US7577834B1 (en) 2000-05-09 2009-08-18 Sun Microsystems, Inc. Message authentication using message gates in a distributed computing environment
US6954747B1 (en) 2000-11-14 2005-10-11 Microsoft Corporation Methods for comparing versions of a program
US6993760B2 (en) 2001-12-05 2006-01-31 Microsoft Corporation Installing software on a mobile computing device using the rollback and security features of a configuration manager
US7103878B2 (en) 2001-12-13 2006-09-05 Hewlett-Packard Development Company, L.P. Method and system to instrument virtual function calls
US6985909B2 (en) 2001-12-28 2006-01-10 Sap Ag Modified class loaders and methods of use
US7281242B2 (en) 2002-01-18 2007-10-09 Bea Systems, Inc. Flexible and extensible Java bytecode instrumentation system
US20030163608A1 (en) * 2002-02-21 2003-08-28 Ashutosh Tiwary Instrumentation and workload recording for a system for performance testing of N-tiered computer systems using recording and playback of workloads
US7058957B1 (en) 2002-07-12 2006-06-06 3Pardata, Inc. Cluster event notification system
US7870431B2 (en) 2002-10-18 2011-01-11 Computer Associates Think, Inc. Transaction tracer
US8418145B2 (en) 2002-11-07 2013-04-09 Ca, Inc. Simple method optimization
US7206807B2 (en) 2003-01-21 2007-04-17 Bea Systems, Inc. Asynchronous invoking a remote web service on a server by a client who passes on a received invoke request from application code residing on the client
US7114150B2 (en) 2003-02-13 2006-09-26 International Business Machines Corporation Apparatus and method for dynamic instrumenting of code to minimize system perturbation
JP2004264914A (ja) * 2003-02-24 2004-09-24 Intellaset:Kk システム性能測定分析装置
US7496903B2 (en) 2003-08-12 2009-02-24 Hewlett-Packard Development Company, L.P. Synthesizing application response measurement (ARM) instrumentation
US7293260B1 (en) 2003-09-26 2007-11-06 Sun Microsystems, Inc. Configuring methods that are likely to be executed for instrument-based profiling at application run-time
US7469262B2 (en) 2003-12-29 2008-12-23 Oracle International Corporation Customizable metadata merging framework
US7359831B2 (en) 2004-05-21 2008-04-15 Bea Systems, Inc. Diagnostic context
US7395458B2 (en) 2004-05-21 2008-07-01 Bea Systems, Inc. Diagnostic instrumentation
US7562341B2 (en) 2004-05-24 2009-07-14 Sap Ag Deploy callback system with bidirectional containers
US7546593B2 (en) 2004-05-28 2009-06-09 Sap Ag Common class loaders
US7614045B2 (en) 2004-09-24 2009-11-03 Sap (Ag) Sharing classes and class loaders
US20060174226A1 (en) 2005-02-03 2006-08-03 Sytex, Inc. Methods, Test Systems And Computer-Readable Medium For Dynamically Modifying Flow Of Executable Code
US7926042B2 (en) 2005-10-31 2011-04-12 Hewlett-Packard Development Company, L.P. System and method for dynamic instrumentation
US20070107057A1 (en) 2005-11-10 2007-05-10 Docomo Communications Laboratories Usa, Inc. Method and apparatus for detecting and preventing unsafe behavior of javascript programs
US7483927B2 (en) 2005-12-01 2009-01-27 International Business Machines Corporation Method for merging metadata on files in a backup storage
US20070150870A1 (en) 2005-12-22 2007-06-28 International Business Machines Corporation Method and apparatus for context oriented computer program tracing and visualization
US20070234307A1 (en) 2006-03-06 2007-10-04 Chi-Keung Luk Methods and apparatus to inline conditional software instrumentation
JP4722740B2 (ja) 2006-03-22 2011-07-13 株式会社沖データ 媒体搬送装置、及び画像形成装置
WO2007113542A1 (en) * 2006-03-31 2007-10-11 British Telecommunications Public Limited Company Server computer component
US8261244B2 (en) 2006-06-02 2012-09-04 Microsoft Corporation Arbitrary runtime function call tracing
US20080034352A1 (en) 2006-06-29 2008-02-07 Mckinney Howard M System and method for determining unimportant probe locations by examination of byte code to identify method by name pattern
US8464225B2 (en) 2007-05-06 2013-06-11 Dynatrace Software Gmbh Method and system for adaptive, generic code instrumentation using run-time or load-time generated inheritance information for diagnosis and monitoring application performance and failure
US8151277B2 (en) 2007-05-15 2012-04-03 Dynatrace Software Gmbh Method and system for dynamic remote injection of in-process agents into virtual machine based applications
US20080148242A1 (en) 2006-12-18 2008-06-19 Computer Associates Think, Inc. Optimizing an interaction model for an application
US8079020B2 (en) 2007-03-05 2011-12-13 Microsoft Corporation Preferential path profiling
US8365018B2 (en) 2007-06-19 2013-01-29 Sand Holdings, Llc Systems, devices, agents and methods for monitoring and automatic reboot and restoration of computers, local area networks, wireless access points, modems and other hardware
US20090112667A1 (en) 2007-10-31 2009-04-30 Ken Blackwell Automated Business Process Model Discovery
US8464270B2 (en) 2007-11-29 2013-06-11 Red Hat, Inc. Dependency management with atomic decay
WO2009095741A1 (en) 2008-02-01 2009-08-06 The Mathworks, Inc Selective code instrumentation for software verification
US8019863B2 (en) 2008-03-28 2011-09-13 Ianywhere Solutions, Inc. Synchronizing events between mobile devices and servers
JP2010033543A (ja) * 2008-06-24 2010-02-12 Smg Kk ソフトウエア動作監視システム、そのクライアントコンピュータおよびサーバコンピュータ、並びに、そのプログラム
US20100131930A1 (en) 2008-11-21 2010-05-27 International Business Machines Corporation Selective Code Coverage Instrumentation

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006260588A (ja) 1998-08-17 2006-09-28 Microsoft Corp 分散コンポーネントアプリケーションでの待機メソッド呼び出し方法
US7047521B2 (en) 2001-06-07 2006-05-16 Lynoxworks, Inc. Dynamic instrumentation event trace system and methods
US20080288212A1 (en) 2007-05-15 2008-11-20 Bernd Greifeneder Method and system for processing application performance data ouside of monitored applications to limit overhead caused by monitoring
US20090254889A1 (en) 2008-04-03 2009-10-08 International Business Machines Corporation Just-in-time dynamic instrumentation

Also Published As

Publication number Publication date
JP2011238233A (ja) 2011-11-24
US8566800B2 (en) 2013-10-22
EP2386955B1 (en) 2013-07-10
JP5798372B2 (ja) 2015-10-21
KR20110124733A (ko) 2011-11-17
EP2386955A1 (en) 2011-11-16
US20110283264A1 (en) 2011-11-17

Similar Documents

Publication Publication Date Title
KR101705265B1 (ko) 동적 인스트루먼테이션을 통한 커스텀 코드의 진단을 스트림라인하기위한 메소드 콜의 검출
KR101669630B1 (ko) 특정된 트랜젝션 콘텍스트에서의 소프트웨어의 조건부의 동적 인스트루먼테이션
EP2442230B1 (en) Two pass automated application instrumentation
KR101650110B1 (ko) 콜백을 사용하여 소프트웨어의 동적 계측을 위한 고장안전 메커니즘
US8752015B2 (en) Metadata merging in agent configuration files
US7877642B2 (en) Automatic software fault diagnosis by exploiting application signatures
US8307345B2 (en) Intelligent engine for dynamic and rule based instrumentation of software
US7698691B2 (en) Server application state
US9021448B1 (en) Automated pattern detection in software for optimal instrumentation
US20130152064A1 (en) Classloader/Instrumentation Approach For Invoking Non-Bound Libraries
US7496615B2 (en) Method, system and article for detecting critical memory leaks causing out-of-memory errors in Java software
US20050204342A1 (en) Method, system and article for detecting memory leaks in Java software
US9588872B2 (en) Discovery of code paths
US10255158B2 (en) Monitoring and diagnostics of business transaction failures
US20080244324A1 (en) Method and system for providing enhanced exception messages for exceptions thrown by virtual machines

Legal Events

Date Code Title Description
N231 Notification of change of applicant
A201 Request for examination
A302 Request for accelerated examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant