KR20120063496A - 경량 서비스 기반의 동적 바이너리 재작성기 프레임워크 - Google Patents

Abstract

프로그램 분석을 위해 별도의 코어를 활용하는 샘플링 기반의 DBR 프레임워크. 상기 프레임워크는 하드웨어 성능 모니터, 별도의 프로세스로서 실행되는 DBR 서비스, 및 클라이언트 프로세스 내에서 실행되는 경량 DBR 에이전트를 포함한다. 상기 DBR 서비스는 하드웨어 성능 모니터로부터 샘플들을 종합하고, 핫 샘플들 주위의 프로그램 구조를 추론함으로써 영역 선택을 수행하고, 선택된 영역들에 대해 변환들을 수행하고(예컨대, 최적화), 대체 코드를 발생시킨다. 그런 다음, 상기 DBR 에이전트는 상기 대체 코드를 사용하도록 상기 클라이언트 프로세스를 패치한다.

Description

경량 서비스 기반의 동적 바이너리 재작성기 프레임워크{A LIGHTWEIGHT SERVICE BASED DYNAMIC BINARY REWRITER FRAMEWORK}

본 발명은 정보 핸들링 시스템에 관한 것이며, 더욱 상세하게는 프로그램 실행을 모니터링하는 것에 관한 것이고 더욱 상세하게는 동적 바이너리 재작성기에 관한 것이다.

클라이언트 프로세스에서 실행중인 컴퓨터 애플리케이션 프로그램을 모니터링할 때, 모니터링 프로그램은 보다 자주 실행되는 코드(즉, 핫 코드(hot code)) 영역들을 결정하기 위해 클라이언트 프로세스를 분석해야될 수 있다. 이러한 모니터링은 본래의 애플리케이션 소스 코드(original application source code)가 쉽게 수정될 수 없거나 재컴파일될 수 없을 때 시스템들에 존재할 수 있다. 모니터링에 이용가능한 정보가 단지 런타임(runtime) 정보뿐일 때, 이들 영역들의 위치를 찾고 구성하는 것은 도전적일 수 있다.

프로그램의 실행을 모니터링하고 자주 실행되는 코드(즉, 핫 코드)를 최적화하여 성능을 개선하기 위해 동적 바이너리 재작성기(dynamic binary rewriter, DBR)의 특정 유형인 동적 바이너리 최적화기(dynamic binary optimizer, DBO)를 사용하는 것은 알려져 있다. 공지의 DBO들은 일반적으로 2개의 범주로 나뉘는데, 2개의 범주는 해석 기반의 DBO(Interpretation based DBO)와 샘플링 기반의 DBO(Samplig based DBO)이다. 해석 기반의 DBO는 프로그램의 동적 명령어들을 관찰하기 위해 인터프리터(interpreter)나 저스트-인-타임 컴파일러(just-in-time compiler)를 활용한다. 샘플링 기반의 DBO는 인터프리터를 없애고 핫 코드를 식별하기 위해 낮은 오버헤드의 샘플링 기반의 기법들을 사용한다. 공지의 DBO들은 변환을 위해 핫 트레이스(hot trace)들을 선택한다. 트레이스는 단일 입구, 다중 출구의 프로시저간(interprocedural) 실행 경로이다.

DBR은 어떠한 정적 프로그램 정보(static program information)를 필요로 함이 없이 원래의 바이너리들 상에서 동작한다는 점을 제외하고는 관리되는 런타임 환경(managed run time environment)과 유사하다.

본 발명에 따르면, 프로그램 분석을 위해 별도의 코어를 활용하는 샘플링 기반의 DBR 프레임워크가 제시된다. 상기 프레임워크는 하드웨어 성능 모니터, 별도의 프로세스로서 실행되는 DBR 서비스, 및 클라이언트 프로세스 내에서 실행되는 경량 DBR 에이전트를 포함한다. DBR 서비스는 하드웨어 성능 모니터로부터 샘플들을 종합하고, 핫 샘플들 주위의 프로그램 구조를 추론함으로써 영역 선택을 수행하고, 선택된 영역들에 대해 변환들을 수행하고(예컨대, 최적화), 대체 코드를 발생시킨다. 그런 다음, DBR 에이전트는 대체 코드를 사용하도록 클라이언트 프로세스를 패치한다.

상기 DBR은 사전 정적 정보를 필요로 함이 없이 원래의 바이너리에 대해 동작한다. 따라서, DBR은 소스 코드에서는 이용가능하지 않은 레거시 바이너리 또는 라이브러리를 변환할 수 있다. 또한, 런타임에서 동작함으로써, DBR은 컴파일시에 이용가능하지 않을 수 있는 변환 기회들을 활용한다. 예를 들어, DBR은 현재 프로그램 입력의 거동을 기반으로 변환들을 수행하고, 특정 아키텍처에 맞게 프로그램을 튜닝하고, 동적으로 링크된 라이브러리들(dynamically linked libraries)에 걸쳐 변환들을 수행할 수 있다.

본 발명은 첨부된 도면들을 참조함으로써 더욱 잘 이해될 수 있으며, 본 발명의 수많은 목적들, 특징들, 및 장점들도 당해 기술분야의 통상의 기술자들에게 명백해질 것이다. 여러 도면들에 걸쳐 동일한 참조 번호의 사용은 비슷하거나 유사한 요소를 표시한다.
도 1은 동적 바이너리 재작성기를 가지는 컴퓨터 시스템의 시스템 블록도를 도시한 것이다.
도 2는 서비스 기반의 동적 바이너리 재작성기 프레임워크의 블록도를 도시한 것이다.
도 3은 동적 바이너리 재작성기의 영역 선택 동작에 대한 수도 코드 표현을 도시한 것이다.
도 4는 한 예시적인 클라이언트 프로그램 상에서 동적 바이너리 재작성기의 핫 코드 발견 동작을 수행한 결과의 블록도를 도시한 것이다.
도 5는 한 예시적인 클라이언트 프로그램 상에서 동적 바이너리 재작성기의 코드 파티셔닝 동작을 수행한 결과의 블록도를 도시한 것이다.
도 6은 한 예시적인 클라이언트 프로그램 상에서 동적 바이너리 재작성기의 핫 호출 인라이닝 동작을 수행한 결과의 블록도를 도시한 것이다.
도 7은 한 예시적인 클라이언트 프로그램 상에서 동적 바이너리 재작성기의 패치 포인트 선택 동작을 수행한 결과의 블록도를 도시한 것이다.
도 8은 한 예시적인 클라이언트 프로그램 상에서 동적 바이너리 재작성기의 코드 프루닝 동작을 수행한 결과의 블록도를 도시한 것이다.
도 9는 한 예시적인 클라이언트 프로그램 상에서 동적 바이너리 재작성기의 완전한 영역 선택 동작을 수행한 결과의 블록도를 도시한 것이다.
도 10은 핫 코드 발견 동작의 수도 코드 표현을 도시한 것이다.
도 11은 코드 파티셔닝 동작의 수도 코드 표현을 도시한 것이다.
도 12는 패치 포인트 선택 동작의 수도 코드 표현을 도시한 것이다.

도 1을 간략히 보면, 컴퓨터 시스템(100)의 시스템 블록도가 도시되어 있다. 컴퓨터 시스템(100)은 프로세서(102), 입력/출력(I/O) 디바이스(104)(예컨대, 디스플레이, 키보드, 마우스, 및 관련 제어기들이며, 그 각각은 원격으로 컴퓨터 시스템(100)에 연결될 수 있음), RAM(random access memory)과 같은 휘발성 메모리 및 하드 디스크 및 드라이브와 같은 비휘발성 메모리를 포함하는 메모리(106), 광학 디스크 및 드라이브 및 다른 메모리 디바이스들과 같은 기타 저장 디바이스(108), 및 다양한 기타 서브시스템(110)을 포함하며, 이들 모두는 하나 이상의 버스(112)를 통해 상호 연결된다.

컴퓨터 시스템은 동적 바이너리 재작성기(dynamic binary rewriter)(130)를 더 포함하며, 이는 메모리(106)에 저장되고 프로세서(102)(또는 프로세서 내의 코어 또는 별도의 연결된 프로세서(미도시됨))에 의해 실행가능하다. 동적 바이너리 재작성기(130)는 프로세서(102) 내에 포함된 하드웨어 성능 모니터(hardware performance monitor, HPM)(132)와 상호 작용한다. 한 실시예에서, 하드웨어 성능 모니터(132)는 명령어 기반의 샘플링(instruction based sampling, IBS)을 지원한다. 명령어 기반의 샘플링은 아키텍처 이벤트를 엄밀히 특정 명령어에 기인하는 것으로 보는 통계적 샘플링 기법이다. 특정 실시예들에서, IBS는 각 샘플링 구간에서 인출 단계(fetch stage) 동안 명령에 태그(tag)를 붙인다. 태그가 붙은 명령어의 실행 동안 발생하는 임의의 아키텍처 이벤트들은 HPM에서 발생된 샘플들에서 보고된다. 다른 실시예들은 아키텍처 이벤트를 특정 명령어에 기인하는 것으로 보고 그 이벤트를 보고하기 위한 다른 방법들을 사용할 수도 있다.

도 2를 보면, 서비스 기반의 동적 바이너리 재작성기 프레임워크(service based dynamic binary rewriter framework)(130)의 블록도가 도시되어 있다. 더욱 구체적으로, DBR 프레임워크(130)는 샘플링 기반의 접근법을 사용한다. 서비스 기반의 동적 바이너리 재작성기 프레임워크(130)는 하드웨어 성능 모니터(132), DBR 서비스 프로세스(DBR service process)(212), 및 경량 DBR 에이전트(lightweight DBR agent)(214)를 포함한다. DBR 서비스 프로세스(212)는 별도의 프로세스로서 실행되고 경량 DBR 에이전트는 클라이언트 프로세스(220) 내에서 실행된다. HPM(132)은 낮은 오버헤드 프로파일링(overhead profiling)을 제공한다. DBR 서비스 프로세스(212)는 영역 선택(region selection) 및 대체 코드 발생(replacement code generation)을 제공하기 위해 HPM(132)으로부터 샘플들을 종합(aggregate)하고 종합된 샘플들을 분석한다. 그런 다음, DBR 에이전트(214)는 대체 코드를 실행하기 위해 클라이언트 프로세스(220)를 패치(patch)한다(221). DBR 서비스 프로세스(212)를 클라이언트 프로세스의 실행으로부터 디커플링(decouple)함으로써, 상기 방법은 클라이언트 프로세스에 대한 성능 영향을 최소화하면서 실체적 분석을 수행한다.

서비스 기반의 동적 바이너리 재작성기 프레임워크(200)는 클라이언트 프로세스 실행에 관한 복수의 유형의 정보를 수집하기 위해 샘플링을 사용한다. 일부 실시예들에서, 정보를 수집하기 위해 명령어 기반의 샘플링이 사용된다. 다른 실시예들은 다른 샘플링 방법들을 사용할 수 있다. 더욱 구체적으로, 복수의 유형의 정보는 명령어 포인터 주소 정보, 브랜치 방향 정보를 포함하며 또한 로드 타겟 주소 정보(load target address information)를 포함하여 추가적인 정보를 포함할 수 있지만, 이들로만 제한되는 것은 아니다. 명령어 포인터(instruction pointer, IP) 주소 정보는 샘플과 관련된 명령어의 주소를 포함한다. 브랜치 방향 정보(branch direction information)는 만일 샘플 명령어가 조건부 브랜치 명령어(conditional branch instruction)인 경우 조건 값을 포함한다. 로드 타겟 주소 정보는 만일 샘플링된 명령어가 로드인 경우 읽히는 메모리 위치의 주소를 포함한다.

DBR 에이전트(214)는 클라이언트 프로세스 내에서 실행되는 경량 공유 라이브러리(lightweight shared library)이다. 시작시에, DBR 에이전트(214)는 클라이언트 프로세스 주소 공간으로 자동으로 로드되고 초기화된다. 초기화는 클라이언트 프로세스(220) 내에서 DBR 에이전트(214)를 구동하는 새로운 쓰레드(thread)를 생성한다. DBR 에이전트(214)는 DBR 서비스 프로세스(212)와 통신 연결을 구성하고 대체 코드(232)를 보유하는 공유 메모리 공간(shared memory space)(230)을 할당한다. 연결을 관리하는 동안, DBR 에이전트(214)는 DBR 서비스 프로세스(212)에 의해 직접적으로 공유 메모리에 배치된 대체 코드를 패치(patch) 및 언패치(unpatch)하라는 요청들과 같은 메시지들에 응답한다. DBR 에이전트(214)는 또한 주의를 요할 수 있는 라이브러리 호출(library call)들의 후킹(hooking)(예컨대, 쓰레드 생성 및 페이지 보호 변경)과 에러 핸들링(error handling)의 수행(예컨대, DBR 서비스 프로세스(212)와의 통신 상실)을 포함하여 여러 가지 작업들을 수행한다.

DBR 서비스 프로세스(212)는 클라이언트 프로세스(220)와 별도의 프로세스로서 동작하며, 일부 실시예들에서 별도의 프로세서 코어(다중 코어 시스템의) 상에서 실행되거나 또는 별도의 프로세서(다중 프로세서 시스템의) 상에서 실행될 수 있다. DBR 서비스 프로세스(212)를 클라이언트 프로세스와 디커플링함으로써, DBR 서비스 프로세스(212)는 클라이언트 프로세스(220)와 동시에 실행될 수 있다. 또한, 디커플링은 메모리 사용을 최소화하고 클라이언트 프로세스와의 공유 라이브러리들을 방지한다. 또한, 디커플링은 단일 DBR 서비스 프로세스로 하여금 다중 클라이언트 프로세스들을 지원할 수 있게 하고 전 시스템 범위의 자원(resource)들을 관리할 수 있게 한다.

DBR 서비스 프로세스(212)는 제어 쓰레드(control thread)(240)를 포함하며, 이 쓰레드는 모든 DBR 에이전트들과의 통신을 관리하고 DBR 서비스의 다양한 양상들을 조정(coordinate)한다. 새로운 클라이언트 프로세스가 시작될 때, 각각의 DBR 에이전트는 DBR 서비스에 연결한다. 최초 연결시에, 제어 쓰레드는 클라이언트 프로세스에 대한 정보와 DBR 에이전트에 의해 생성된 공유 메모리 영역(232)에 대한 정보를 획득한다. 제어 쓰레드(240)는 공유 메모리(232) 주소 공간을 DBR 서비스 프로세스(212)의 주소 공간으로 매핑(map)한다. 제어 쓰레드(240)는 클라이언트 프로세스가 수정되어서는 안 되는 프로그램을 실행하고 있는지를 결정할 수 있고 DBR(130)에 의한 추가 핸들링을 디스에이블(disable)시킬 수 있다.

제어 쓰레드(240)는 프로파일 스냅샷(profile snapshot)을 수집하기 위해 짧은 주기 동안 HPM(132)을 주기적으로 활성화한다. 제어 쓰레드(240)는 HPM(132)으로부터 샘플들을 수신하고 클라이언트 프로세스 및 IP 주소들을 기반으로 샘플들을 종합한다. 단지 짧은 주기들 동안만 HPM(132)을 활성화함으로써, 클라이언트 프로세스는 대부분의 시간 동안 샘플 수집 오버헤드에 의해 방해받지 않고 실행되도록 남아 있다. 주기의 길이를 조정함으로써, DBR(132)은 대체 코드를 발생시킴으로써 얻는 이점들에 대하여 샘플링 오버헤드를 균형 맞출 수 있다. 간헐적으로 HPM(132)을 활성화함으로써, DBR(132)은 클라이언트 프로세스 프로그램 실행에서 일어날 수 있는 상태 천이(phase transition)에 응답할 수 있다. 일부 실시예들에서, 샘플링 오버헤드는 충분히 낮아서 HPM(132)이 주기적으로 사용되는 것이 아니라 HPM(132)이 연속적으로 사용되는 것이 가능할 수 있다.

DBR 서비스 프로세스(212)는 또한 일꾼 쓰레드들(worker threads)(242)의 풀(pool)을 포함할 수 있으며, 이는 제어 쓰레드(240)에 의해 생성된다. 프로파일 스냅샷을 취한 후에, 제어 쓰레드(240)는 전반적인 시스템 부하에 의거하여 얼마나 많은 일꾼 쓰레드들이 투입될 수 있는지를 결정한다. 제어 쓰레드(240)는 또한 어느 클라이언트 프로세스들이 수정되어야하고(만일 존재한다면) 어떤 순서로 수정되어야 하는지를 결정한다. 그런 다음, 제어 쓰레드(240)는 일꾼 쓰레드들을 시작시키고 그 쓰레드들이 그 다음 스냅샷 구간까지 슬립(sleep)하기 전에 완료하기를 기다린다. 제어 쓰레드(240)는 또한 대체 코드의 효율성을 평가하고 적절하다면 대체 코드를 언패치할 수 있다. 예를 들어, 제어 쓰레드(240)는 대체 코드에 있는 스냅샷 샘플들의 비율을 모니터링할 수 있다.

일단 일꾼 쓰레드(242)가 활성화되었다면, 일꾼 쓰레드는 특정 클라이언트 프로세스에 대하여 영역 선택과 대체 코드 발생을 수행한다. 일꾼 쓰레드(242)는 종합된 샘플들을 액세스하고, 클라이언트 프로세스 주소 공간을 읽고, 대체 코드를 클라이언트 프로세스의 공유 메모리에 배치하고, DBR 에이전트(214)에게 패치들을 설치(install)할 것을 통지하기 위해 제어 쓰레드(240)에 의해 제공되는 기능들을 사용한다. 만일 클라이언트 프로세스의 주소 매핑이 영역 선택 및 대체 코드 발생이 본래 수행되었던 때의 상태와 호환되지 않는 방식으로 변하였다면(예컨대, 참조된 코드나 데이터가 언로드(unload)된 라이브러리에 포함되거나 또는 페이지 보호가 업데이트되어 더 이상 읽기 전용이 아닌 경우) 대체 코드는 사용되지 않는다. DBR 서비스 프로세스(212)와 DBR 에이전트(214)는 만일 이러한 이벤트들이 발생한다면 대체 코드가 설치되지 않거나 패치되지 않도록 보장하기 위해 협력한다.

도 3을 보면, 동적 바이너리 재작성기(130)의 영역 선택 동작의 수도 코드(pseudo code) 표현이 도시되어 있다. 더욱 구체적으로, DBR(130)은 프로그램에 대한 어떠한 사전 정적 지식도 없이 핫 코드 영역들을 식별하는 영역 선택 동작(300)을 포함한다. DBR 영역 선택 동작(300)은 그 결과들을 수퍼-영역(super-region, SR)들로서 중간 표현(intermediate representation, IR)에 나타낸다. 수퍼-영역들은 임의적 제어 흐름(arbitrary control flow)을 나타낼 수 있으며, 다중 네스트된 루프(nested loop)들로부터의 코드를 포함할 수 있고 다중 프로시저 경계들에 걸칠(span) 수 있다. 수퍼-영역 내에서, IR은 제어 흐름을 단일 입구, 단일 출구의 방향성 비순환 그래프(directed acyclic graph)로서 나타낸다.

그래프의 노드(node)는 기본 블록(basic block, BB)이며, 에지(edge)는 제어 흐름 에지(control flow edge, CFE)이다. 각 SR은 복수의 기본 블록들을 포함한다. 더욱 구체적으로, 각 SR은 시작(start) 기본 블록, 꼬리(tail) 기본 블록, 및 0개 이상의 보디(body) 기본 블록들을 포함한다. 시작 기본 블록은 공통 엔트리 포인트(common entry point)를 제공하는 수도(pseudo) 기본 블록이다. 시작 블록으로부터 나가는 에지들은 엔트리 에지(entry edge)로서 지칭되며 본래의 클라이언트 코드(original client code)로부터 대체 코드로 들어가는 것을 표시하는 수도 에지이다. 꼬리 기본 블록은 공통 엑시트 포인트(common exit point)를 제공하는 수도 기본 블록이다. 꼬리 블록으로 들어가는 에지들은 엑시트 에지(exit edge)로서 지칭되며 대체 코드를 떠나 본래의 클라이언트 코드에서 실행을 계속하는 것을 표시하는 수도 에지이다. 보디 기본 블록들은 실제의 프로그램 코드를 나타낸다. 보디 기본 블록들은 대체 코드를 발생시키기 위해 변환된다.

영역 선택 동작(300)에 의해 생성되는 최종 수퍼-영역들에서, 보디 기본 블록들은 단일의 연결 성분(connected component)을 형성하며, 연결 성분에서 엔트지 에지는 패치 포인트(즉, 대체 코드로 들어가도록 패치되는 클라이언트 프로그램의 주소)를 정의한다. 수퍼-영역의 단일 엔트리 및 엑시트는 전통적인 컴파일러 분석 및 최적화가 가능하게 한다.

영역 선택 동작(300)은 핫 코드 발견 동작(hot code discovery operation)을 수행하는 것으로 시작한다. 다음으로, 영역 선택 동작(300)은 코드 파티셔닝 동작(code partitioning operation)을 수행한다. 다음으로, 영역 선택 동작(300)은 폴-스루-온리 계산(fall-through-only computation)과 핫 호출 인라이닝 동작(hot call inlining operation)을 수행한다. 다음으로, 영역 선택 동작(300)은 패치 포인트 선택 동작(patch point selection operation)과 코드 프루닝 동작(code pruning operation)을 수행한다.

도 4를 보면, 한 예시적인 클라이언트 프로그램 상에서 동적 바이너리 재작성기(130)의 핫 코드 발견 동작을 수행한 결과의 블록도가 도시되어 있다. 핫 코드 발견 동작은 종합된 HPM 샘플들을 핫 샘플 기본 블록들에 대한 시드 주소(seed address)로서 사용한다. 핫 코드 발견 동작은 제어 흐름을 따라가며 순방향(forward)으로 클라이언트 코드를 디스어셈블(disassemble)한다. 발견은 핫인 기본 블록들로부터 특정 개수의 조건부 점프(conditional jump)들을 행함으로써 조절된다. 그 결과는 핫 명령어들 주위의 클라이언트 프로그램 구조를 표현하도록 연결되는 기본 블록들의 세트를 포함하는 단일의 수퍼-영역이다.

도 5를 보면, 한 예시적인 클라이언트 프로그램 상에서 동적 바이너리 재작성기(130)의 코드 파티셔닝 동작을 수행한 결과의 블록도가 도시되어 있다. 코드 파티셔닝 동작은 단일의 수퍼-영역 제어 흐름 그래프의 각 연결 성분의 기본 블록들 및 제어 흐름 에지들을 별도의 수퍼-영역으로 이동시킨다. 코드 파티셔닝 동작은 또한 시작 블록이 별도의 수퍼-영역의 모든 기본 블록들을 지배(dominate)하고 꼬리 블록이 그 모든 기본 블록들을 후지배(post-dominate)하는 것을 보장하기 위해 임의의 필요한 에트리 에지 및 엑시트 에지를 추가한다.

핫 코드 발견 동작이 명령어들을 디스어셈블하는 동안, 핫 코드 발견 동작은 샘플 종합기(sample aggregator)에게 문의하고 샘플 카운트를 생성되는 기본 블록들과 제어 흐름 에지들 상에 기록한다. 그 계승자(successor)로 폴-스루-온리하는 기본 블록은 명시적인 브랜치 명령어들 가지지 않기 때문에, 제어 흐름 에지 상에 기록할 수 있는 샘플이 없다. 따라서, 폴-스루-온리 계산 동작에 의해 폴-스루-온리가 아닌 제어 흐름 에지들의 카운트들로부터 카운트 근사치가 계산된다(예컨대 도 3 참조).

도 6을 보면, 한 예시적인 클라이언트 프로그램 상에서 동적 바이너리 재작성기(130)의 핫 코드 인라이닝 동작을 수행한 결과의 블록도가 도시되어 있다. 핫 호출 인라이닝 동작은 임의의 핫 기본 블록들이 호출 명령어를 포함하는지와 수퍼-영역이 리턴(return) 명령어가 도달가능한 타겟 주소에 해당하는 기본 블록을 가지는지를 결정한다. 만일 이들 조건들이 참(true)이라면 핫 호출 인라이닝 동작은 루틴(routine)을 인라이닝한다.

도 7을 보면, 한 예시적인 클라이언트 프로그램 상에서 동적 바이너리 재작성기(130)의 패치 포인트 선택 동작을 수행한 결과의 블록도가 도시되어 있다. 수퍼-영역에서 핫 코드 발견 동작에 의해 생성된 모든 기본 블록들이 패치될 수 있는 것은 아니다. DBR(130)의 패치 포인트 선택 동작은 각 수퍼-영역에 대하여 좋은(good) 패치 포인트들의 세트를 식별하기 위해 지배자(dominator)와 루프 분석(loop analysis)을 사용한다.

도 8을 보면, 한 예시적인 클라이언트 프로그램 상에서 동적 바이너리 재작성기(130)의 코드 프루닝 동작을 수행한 결과의 블록도가 도시되어 있다. 코드 프루닝 동작으로, 루프를 가지지 않거나, 너무 작다고 생각되거나, 패치 포인트를 가지지 않는 수퍼-영역들은 삭제된다. 또한, 엔트리 에지들을 변경하는 패치 포인트 선택 동작 내에서 생긴 임의의 도달가능하지 않은 기본 블록들과 함께, 단순히 수퍼-영역을 빠져나가는 콜드(cold) 꼬리 기본 블록들은 삭제된다.

도 9를 보면, 한 예시적인 클라이언트 프로그램 상에서 동적 바이너리 재작성기(130)의 완전한 영역 선택 동작(300)을 수행한 결과의 블록도가 도시되어 있다. 생성된 최종 수퍼-영역들이 도시되어 있다.

도 10을 보면, 핫 코드 발견 동작의 한 실시예의 수도 코드 표현이 도시되어 있다. DBR(130)에서, 클라이언트 프로세스는 모든 정적 프로그램 정보(예컨대, 심볼 테이블 및 디버깅 정보)를 벗겨낸 바이너리들을 실행하고 있을 수 있다. 따라서, 핫 코드 발견 동작은 이런 정보 없이 프로그램 구조를 동적으로 발견한다. 간접 호출(indirect call), 간접 점프(indirect jump), 및 리턴과 같은 일부 제어 흐름은 만일 HPM(132)이 적절한 정보를 제공하지 않는다면 따라가기 어려울 수 있다. 심지어 정규 호출(regular call)들의 경우에도 DBR(130)로서는 그것들이 리턴하는지(예컨대, EXIT와 같은 루틴을 호출하는지)를 확신할 수 없기 때문에 어려움을 제공할 수 있다. 컴파일러는 이것들을 루틴 코드의 끝에 배치하고 바로 다음에 루틴 데이터(점프 테이블과 같은)를 배치할 수 있다.

가변 길이 명령어 세트 아키텍처(instruction set architecture, ISA)(예컨대, x86 프로세서 아키텍처와 같은 프로세서 아키텍처들 내에 존재할 수 있는)는 또 다른 난제를 제공한다. 명령어 주소가 알려져 있는 경우, DBR(130)은 오직 순방향으로만 디스어셈블할 수 있다. 가변 길이 인코딩은 이전 명령어들의 시작을 구별하는 것을 극도로 어렵게 만든다. 만일 제어 흐름에 대해 올바르지 않은 가정이 이루어지면, DBR(130)은 실제의 명령어들 중간에서 바이트들을 디스어셈블하게 될 수 있다.

따라서, 핫 코드 발견 동작은 종합된 HPM 샘플들에 의해 식별되는 핫 명령어들에서 시작하여 클라이언트 프로그램의 제어 흐름을 탐색한다. 그것이 생성하는 모든 기본 블록들 및 제어 흐름 에지들은 단일의 수퍼-영역 first_sr에 할당되며, 영역 선택 동작 동안에 할당된다.

핫 코드 발견 동작은 단계적으로 탐색해 가면서 기본 블록의 시작이거나 또는 잠재적으로 기본 블록의 시작이 될 수 있는 각 클라이언트 주소에 대한 지식을 추적(track)한다. 핫 코드 발견 동작은 매핑 데이터 구조(mapping data structure)를 이용하여 추적하며, 매핑 데이터 구조는 각각의 이러한 주소에 대한 별도의 엔트리를 포함한다. 만일 주소가 성공적으로 디스어셈블되었다면, 핫 코드 발견 동작은 그 크기 및 명령어 경계들과 함께 생성된 기본 블록을 기록한다. 만일 주소가 아직 디스어셈블되지 않았다면, 그 크기는 임시로 단일 바이트로 가정되며 이미 생성되었고 그 주소를 타겟으로 하는 제어 흐름 에지들의 세트가 기록된다. 이들 제어 흐름 에지들은 초기에 꼬리 기본 블록에 대한 엑시트 에지들로서 생성되지만, 주소가 디스어셈블되는 경우에는 제어 흐름 에지들은 새로운 기본 블록을 그들의 타겟로서 가지도록 업데이트된다. 게다가, 만일 주소가 디스어셈블될 수 없다고 결정되면, 그 사실이 기록되고 그것으로의 모든 제어 흐름 에지들은 엑시트 에지들로 남아있을 것이다. 매핑 구조는 각 명령어가 오직 한 번만 디스어셈블되는 것을 보장하며 발견 프로세스의 단계적 성질을 지원한다.

단계적 탐색을 관리하기 위해, 작업 리스트(work list)가 핫 코드 발견 동작에 의해 사용되며, 작업 리스트는 이미 발견된 기본 블록들을 포함하고 그 기본 블록들은 그것들의 계승자 제어 흐름을 따를 것이 요구될 수 있다. 기본 블록이 처음에 생성될 때, 기본 블록은 항상 작업 리스트에 놓인다. 핫 코드 발견 동작은 핫 샘플들에 대응되는 주소들의 세트에 대해 샘플 종합기에 질의(query)하는 것으로 시작한다. 이들 주소들 각각에 대해, 핫 코드 발견 동작은 ENSURE-BB 함수를 호출함으로써 기본 블록이 있는지를 확인한다. 기본 블록이 샘플들을 가지는 다중 명령어들을 포함할 수 있기 때문에, starts는 false로서 건네진다. 이는 기본 블록이 요청된 주소에서 시작해야하는 것이 아니라 단지 요청된 주소를 명령어 경계로서 포함하여야 한다는 것을 가리킨다.

다음으로, PROCESS-WORK-LIST 함수가 호출되며, 이 함수는 작업 리스트가 빌 때까지 작업 리스트로부터 기본 블록을 가져오고 기본 블록을 처리한다. 기본 블록을 처리하는 것은 그것의 계승자 제어 흐름 에지들 각각이 타겟 기본 블록을 가지도록 보장하는 것을 포함하며, 이는 다시 추가 기본 블록들을 작업 리스트에 추가할 수 있다. 발견이 핫 코드로부터 얼마나 멀리 탐색할 것인지에 대해 조절하기 위해, 각 기본 블록은 jumps-from-hot, 즉 핫 샘플 기본 블록으로부터 떨어져 있는 조건부 점프들의 개수로 태그(tag)된다. 핫 샘플을 포함하거나 또는 이러한 기본 블록으로부터 무조건부로 도달가능한(unconditionally reachable) 임의의 기본 블록은 jumps-from-hot 값이 0이다. 따라서, 핫 샘플 기본 블록들의 경우에 jfh는 0으로 건네진다. 계승자 제어 흐름 에지들이 jumps-from-hot의 한계치 이하인 경우 단지 계승자 제어 흐름 에지들을 따라간다. 샘플링의 통계적 성질로 인해 실제로 핫인 코드가 상당한 개수의 샘플들을 얻지 못할 수 있다. 이는 매우 작은 기본 블록들의 경우에 특히 문제가 된다. 점프-프롬-핫(jumps-from-hot) 메커니즘은 이런 아티팩트(artifact)들을 제거한다. 또한, 점프-프롬-핫 메커니즘은 핫 코드로 나가고 되돌아가는 짧지만 보다 낮은 빈도로 실행되는 경로들을 SR에 포함되게 하는 역할을 한다. 이는 수퍼-영역을 빠져나가는 것을 방지하고 대체 코드의 이점을 상실하는 것을 방지하면서도 포함되는 비-핫 코드(non-hot code)의 양을 제한한다.

만일 계승자 제어 흐름 에지가 엑시트 에지이면, 제어 흐름 에지의 타겟 주소를 위해 ENSURE-BB 함수가 호출된다. 이 경우에, 소스 기본 블록이 그 주소로 이전(transfer)하고 있기 때문에 기본 블록은 그 주소에서 시작하여야 한다. 만일 엑시트 에지가 아니면 SET-JUMPS-FROM-HOT 함수가 타겟 기본 블록 상에서 호출된다. 만일 제공된 jumps-from-hot이 기본 블록의 현재 값보다 작으면, 기본 블록은 업데이트되고 작업 리스트 상에 다시 놓인다. 이는 더욱 낮은 값이 그것의 계승자들에게 전파될 수 있게 할 것이며, 이는 이전에 한계치를 넘어섰던 제어 흐름 에지들을 탐색하는 결과가 될 수 있다.

사실상 실행된 적이 없는 제어 흐름 경로들을 따라가는 것은 명령어들이 아닌 바이트들이 디스어셈블되게 할 수 있다. 이들 바이트들은 일부 다른 제어 흐름 경로를 따라감으로써 도달가능한 실제 명령어들과 심지어 오버랩(overlap)될 수 있다. 이를 핸들링하기 위해, 매핑은 동일한 주소들을 커버하는 다중 엔트리들이 존재할 수 있게 한다(유일한 규칙은 그것들이 디스조인트(disjoint) 명령어 경계들을 가진다는 것이다). 이를 보장하기 위해, DISASSEMBLE-BASIC-BLOCK 함수는 명령어들을 디스어셈블할 때 그 다음 명령어의 주소가 기존 엔트리의 명령어 경계와 일치하는지를 저렴한 비용으로 결정해야 한다.

이 결정은 위치 데이터 구조(position data structure)에 의해 저렴한 비용으로 달성되며, 이는 그것이 위치되는 주소를 포함하는 범위를 가지는 오버래핑 엔트리들에 대한 정보(만일 존재한다면)를 매핑에 기록한다. 게다가, 위치는 오버래핑 엔트리들 중 어느 것(만일 존재한다면)이 그 주소를 그것의 명령어 경계들 중 하나로서 가지는지를 기록한다(디스조인트 명령어 경계 요건 때문에 기껏해야 하나가 있을 수 있다). 이것은 매치 엔트리(match entry)(핫 코드 발견 동작에서 .entry 표기에 의해 액세스됨)로 지칭된다. 마지막으로, 위치는 또한 다음 엔트리에 대한 정보를 기록한다. 다음 엔트리는 위치 주소보다 큰 것으로서 가장 작은 주소를 갖는 것이다(다시, 동일한 이유로 이들 중 기껏해야 하나가 있을 수 있다). 위치는 저렴한 비용으로 새로운 주소로 진행될 수 있으며 그것의 모든 기록된 정보를 단계적으로 업데이트한다.

한 주소에 대한 오버래핑 엔트리들을 계산하는 것을 가능하게 하기 위해, 엔트리는 만일 존재한다면 그것의 부모 엔트리(parent entry), 최소 어드레싱된 오버래핑 엔트리를 기록한다. 오버래핑 코드들에 대한 조건들은 드물기 때문에 이는 수행되어야 하는 검색(search)을 대개는 0으로 제한한다. 반대로, 엔트리들이 생성되거나 업데이트될 때(NEW-BB 함수, MERGE-ENTRY 함수 등에 의해), 부모 엔트리를 저렴한 비용으로 계산하고 어느 다른 엔트리들이 또한 그들의 부모 엔트리가 업데이트되는 것이 필요할 수 있는지를 결정하기 위해 필요한 오버래핑 엔트리들을 포함하는 위치가 항상 제공된다.

ENSURE-BB 함수는 addr를 보유한 엔트리가 이미 존재하는지를 결정하기 위해 FIND-ENTRY 함수를 사용한다. 만일 FIND-ENTRY 함수가 주소에서 starts하는 엔트리를 리턴하도록 요청받았다면, FIND-ENTRY 함수는 기본 블록을 가지는 매치 엔트리를 가지는지(주소가 이미 디스어셈블되었는지를 가리킴)를 결정하기 위해 GET-POSITION 함수에 의해 리턴되는 위치를 점검한다. 만일 그렇다면, FIND-ENTRY 함수는 엔트리를 스플릿(split)하고 만일 주소가 기본 블록의 시작이 아닌 경우에는 관련 기본 블록을 스플릿한다. 만일 기본 블록이 작업 리스트에 있었다면, 그것은 스플릿된 하부에 해당하는 새로운 기본 블록에 대해 교환될 수 있다. 이는 기본 블록이 그 계승자를 탐색하는 작업 리스트 상에 있고, 스플릿된 기본 블록의 상부에 대한 기본 블록은 단지 폴-스루-온리 제어 흐름 에지를 가지며, 이제 탐색을 필요로 하는 제어 흐름을 가지는 것은 하부이기 때문이다.

FIND-ENTRY 함수에 의해 ENSURE-BB 함수로 리턴되는 위치가 기존의 엔트리가 이미 그 주소를 명령어 경계로서 가진다는 것을 가리키는 매치 엔트리를 가지는지를 결정하기 위해 그 위치가 점검된다. 만일 매치 엔트리가 지원되지 않는 것으로서 마킹(mark)되었다면, 그 주소에서 생성되는 기본 블록은 있을 수 없다. 만일 제어 흐름 에지의 타겟을 대표하여 호출된다면, 제어 흐름 에지는 기존의 에지에 남아 있을 것이다. 만일 매치 엔트리가 기본 블록을 가진다면, 그 엔트리는 이미 디스어셈블된 것이고 더 이상의 조치는 필요치 않는다. 하지만, jfh가 더 낮은 경우에는 기본 블록의 jumps-from-hot이 업데이트되며, 이 경우에 더 낮은 값이 전파될 수 있도록 기본 블록은 작업 리스트에 다시 넣어질 것이다.

이 시점에서, DBR(130)은 addr에서 시작하여 어떠한 명령어도 이전에 디스어셈블되지 않았다는 것을 알고 있다(그렇지 않으면, 그것을 포함하는 엔트리가 존재하였을 것이다). 그러므로, DBR(130)은 DISASSEMBLE-BB 함수를 호출하며, 이 함수는 다수의 조건들 중 임의의 것이 존재할 때까지 명령어들을 디스어셈블하고 위치로 진행한다. 더욱 구체적으로, DBR(130)이 제어 이전 명령어(control transfer instruction)에 도달하거나, 지원되지 않거나 불법(illegal) 명령어를 만나거나, 또는 존재하지 않거나 읽기 전용이 아닌 실행가능한 클라이언트 메모리를 액세스 시도할 때까지 DBR(130)은 명령어를 디스어셈블하고 위치로 진행한다. 게다가, 일부 명령어들은 그들 자신의 기본 블록에 있을 것이 요구된다. 대체가능한 것으로, DBR(130)은 위치로 진행한 후에 그 위치가 매치 엔트리를 가져서 DBR(130)이 다음의 엔트리에 도달하였거나 오버래핑 엔트리의 명령어 경계와 동기화되었다는 것을 가리킬 때까지 명령어들을 디스어셈블하고 위치로 진행한다. 대체가능한 것으로, DBR(130)이 패치 명령어의 일부인 바이트를 만날 때까지(공유 메모리 관리자에게 문의하여 결정됨) 명령어들을 디스어셈블하고 위치로 진행한다. 패치는 오직 하나의 위치로만 나아갈 수 있으며, DBR(130)이 동일한 클라이언트 코드에 대해 복수의 버전의 대체 코드를 만드는 것은 코드 지역성(locality)의 유효성(effectiveness)을 감소시킬 것이기 때문에 바람직하지 않다. 제어 쓰레드는 대체 코드의 유효성을 모니터링하고 그것을 제거하는 것을 선택할 수 있으며, 관련 클라이언트 코드가 다시 후보(candidate)가 될 수 있도록 한다.

DISASSEMBLE-BB 함수는 BB의 모든 제어 흐름 타겟들의 주소, 모든 타겟들의 샘플 카운트, 명령어들의 총 샘플 카운트, 첫번째 패치가능한 명령어의 샘플들을 갖는 첫번째 명령어의 주소, 및 명령어 경계들을 포함하는 제어 흐름과 함께 기본 블록의 마지막 명령을 다음 주소 위치를 리턴한다.

제어 흐름 명령어들의 타겟 주소들은 복수의 방법들 중 하나에 의해 결정된다. (1) 만일 마지막 명령어가 조건부 점프(conditional jump)인 경우, DISASSEMBLE-BB 함수는 HPM 브랜치 방향 샘플 정보를 사용한다. (2) 메모리 간접 제어 이전들의 경우, DISASSEMBLE-BB 함수는 리터럴(literal) 주소나 HPM 로드 타겟 주소 샘플 정보를 적절히 사용한다. DISASSEMBLE-BB 함수는 가능한 타겟 주소들을 찾기 위해 이들 위치들을 판독한다. (3) 만일 읽기 전용 메모리로부터 로드한다면, DISASSEMBLE-BB 함수는 주소를 신뢰하고, 그렇지 않으면 명령어가 실행된 이후에 위치가 변경되었을 수 있기 때문에 DISASSEMBLE-BB 함수는 단지 그것이 또한 샘플들을 가지는 경우에 주소를 신뢰한다. (4) 리터럴이 아닌 읽기 전용 메모리 우회(non-literal read-only memory indirect)의 경우, DISASSEMBLE-BB 함수는 또한 다른 타겟들이 존재할 수 있다는 것을 표시하는 수도-언노운-타겟(pseudo-unknown-target)을 포함한다. (5) 레지스터 우회(register indirect)는 DISCOVER-REGISTER-INDIRECT-CODE 함수에 의해 핸들링된다. (6) 만일 타겟 주소들을 직접 제공하는 HPM(132)이 이용가능하다면, DISASSEMBLE-BB 함수는 그 정보를 대신에 사용할 수 있다.

유의할 점은 DISASSEMBLE-BB 함수는 어떠한 명령어도 디스어셈블할 수 없을 수도 있다는 것이다. 이 경우에, ENSURE-BB 함수는 SET-UNSUPPORTED 함수를 호출하며, 이 함수는 필요하다면 엔트리를 매핑에 생성하고 그 엔트리를 지원되지 않는 것(unsupported)으로서 마킹한다. 임의의 대기중인(pending) 제어 흐름 에지들은 엑시트 에지들로 남아 있을 것이다.

만일 다음 위치가 그 주소에 매칭 엔트리가 있다고 가리키면, ENSURE-BB 함수는 매칭 엔트리가 방금 디스어셈블된 명령어들을 또한 포함하도록 확장될 수 있는지 여부를 점검하기 위해 CAN-MERGE-ENTRY 함수를 호출한다. 이 조건은 만일 다음 엔트리가 우연히 실제 기본 블록의 중간에 있었던 핫 샘플로부터 생성되었다면 발생할 수 있다. 병합(merge)은 만일 다음의 모두가 참일 경우 일어날 수 있다. (1) control_flow의 값이 디스어셈블된 명령어들이 폴-스루-온리로 끝났다는 것을 표시한다. (2) 다음의 위치가 매치 엔트리를 가진다. (3) 그 매치 엔트리가 다음 위치의 주소에서 시작한다. 이 조건은 만일 DISASSEMBLE-BB 함수가 오버래핑 엔트리와 동기화된 경우는 아닐 것이다. 그 경우에, 오버래핑 엔트리는 스플릿해야 하며, 이는 ENSURE-BB 함수가 폴-스루 제어 흐름 에지를 추가할 때 자동적으로 발생할 것이다. (4) 다음 엔트리가 선행자(predecessor) 제어 흐름 에지들이 없는 기본 블록을 가지고 그 자신의 기본 블록에 있어야 할 명령어를 가지지 않는다. 기본 블록이 없는 엔트리들은 대기 제어 흐름 에지들의 타겟으로서 지원되지 않거나 아니면 생성된다.

MERGE-ENTRY 함수는 pos.entry의 값에 의해 특정되는 매핑 엔트리가 만일 존재한다면 그것을 삭제(delete)함으로써 병합 동작(merge operation)을 수행하고, 새로운 주소에서 시작하기 위해 다음 엔트리의 정보와 그 관련 기본 블록의 정보를 업데이트하고, 업데이트된 위치를 리턴한다. 만일 그렇지 않으면, 기본 블록을 생성하고 그 기본 블록을 pos.entry 에 의해 특정되는 매핑 엔트리와 관련시키기 위해 NEW-BB 함수가 호출되어 필요하다면 하나를 생성한다. 어느 경우에나, 기본 블록의 점프-프롬-핫을 업데이트하고 필요하다면 기본 블록을 작업 리스트에 추가하기 위해 SET-JUMPS-FROM-HOT 함수는 ENSURE-BB 함수에 의해 호출된다(이는 새로운 기본 블록들의 경우 그것들은 디폴트로서 무한정 생성되기 때문에 항상 발생할 것이다). 만일 pos.entry 값에 의해 특정되는 매핑 엔트리가 임의의 대기 제어 흐름 에지들을 가진다면, 제어 흐름 에지들은 엑시트 에지들이 되는 대신에 새로이 생성된 기본 블록에 연결하도록 모두 업데이트된다.

만일 새로운 기본 블록이 생성되었다면 ADD-CONTROL-FLOW 함수는 ENSURE-BB 함수에 의해 호출된다. 이 함수는 기본 블록의 타겟들 각각에 대해 제어 흐름 에지들을 생성한다. 만일 타겟에 대해 기본 블록을 갖는 엔트리가 있다면, 제어 흐름 에지는 단순히 그것에 연결하며, 만일 그렇지 않다면, 엑시트 제어 흐름 에지가 꼬리 기본 블록에 생성되고, 제어 흐름 에지를 타겟 주소에 대한 엔트리의 대기 제어 흐름 에지들에 추가하기 위해 ADD-PENDING-CFE 함수가 호출되어, 필요하다면 하나를 생성한다. 임의의 언노운 타겟들(unknown target)은 꼬리 기본 블록에 연결되고, 이들 타겟들은 주소를 가지지 않기 때문에 언노운 타겟들을 위해 어떠한 엔트리도 생성되지 않는다. 이들 엑시트 제어 흐름 에지는 우회 이전(indirect transfer)이 다른 제어 흐름 에지들에 의해 명시적으로 표현된 것들이 아닌 타겟으로 향하는 결과를 표시한다.

INLINE-HOT-CALLS 함수를 가능하게 하기 위해, 호출들의 제어 흐름이 특별히 표현된다. 먼저, DBR(130)은 호출 명령어가 제어 흐름을 리턴하고 그 후에 뒤따를 것이라고 항상 가정한다. 이는 DBR(130)이 인라이닝(inlining)을 위해 필요한 완전한 제어 흐름 그래프를 가지는 것을 보장한다. 유의할 점은 이것은 사실상 항상 참이지 않을 수 있지만(예컨대, 컴파일러가 알고 있었던 루틴에 대한 호출이 절대 리턴되지 않는다든가, 또는 호출 후에 배치된 리터럴 인수(literal argument) 데이터를 스킵하기 위해 리턴 주소를 조정하는 것에 의해 비표준 방식으로 리턴하는 것), MARK-UNPATCHABLE 함수가 이 문제를 완화시킨다는 것이다. 둘째, DBR(130)은 호출로부터 호출 타겟 기본 블록으로의 제어 흐름을 2개의 제어 흐름 에지들, 즉 호출로부터 꼬리 기본 블록으로의 것과 시작 기본 블록으로부터 호출 타겟 기본 블록으로의 것으로서 표현한다. 이러한 규약은 PARTITION-CODE 함수가 서로 다른 루틴들에 대한 코드를 인라이너를 또한 보조하는 별도의 수퍼-영역들로 구분(segregate)할 수 있도록 한다.

NEW-CFE 함수와 NEW-BB 함수는 이 문제를 자동적으로 처리한다. 만일 호출 타겟 기본 블록이 NEW-CFE 함수가 호출 에지를 만들도록 요청받았을 때 이미 존재하면, 그 함수는 즉시 엔트리 제어 흐름 에지를 생성한다. 만일 그렇지 않으면, 그 함수는 엔트리를 호출 타겟으로서 마킹하고, 그것의 생성은 NEW-BB 함수가 그 엔트리에 대한 기본 블록을 생성할 때까지 연기될 것이다. 리턴 명령어들은 단순히 엑시트 제어 흐름 에지를 가진다.

INLINE-HOT-CALLS 함수가 호출 명령어와 리턴 명령어의 제어 흐름을 수정하거나, 그것들을 수도 명령어들로 변환하거나, 또는 그것들을 삭제하는 것을 용이하게 만들기 위해, DBR(130)은 호출 명령어와 리턴 명령어를 그것들 자신의 기본 블록에 위치시킨다. 캐스케이드(cascaded) 우회 제어 흐름 변환에 관한 우회 제어 흐름 명령어들에 대해서도 동일하다.

DISCOVER-INDIRECT-CODE 함수는 DISASSEMBLE-BB에 의해 발견된 것들을 넘어 우회 제어 흐름 명령어들에 대한 타겟들을 추론하려는 시도를 한다. DISCOVER-INDIRECT-CODE 함수는 선행하는 기본 블록들에 있는 것들을 포함하여 선행하는 명령어들을 검사함으로써 이것을 수행한다. DISASSEMBLE-BB 함수는 선행하는 기본 블록들이 그 당시에 발견되지 않았을 수 있기 때문에 이 검사를 할 수 없다. 만일 DISCOVER-INDIRECT-CODE 함수가 성공한다면, 그것은 타겟들을 ADD-CONTROL-FLOW로 넘겨준다. 이것은 더 많은 기본 블록들을 작업 리스트에 추가할 수 있고, 따라서 DISCOVER-INDIRECT-CODE 함수는 PROCESS-WORK-LIST를 호출한다. 이들 2개의 단계들을 수행하는 것은 더 이상 추가 코드가 발견되지 않을 때까지 반복적으로 수행될 수 있다.

간접 제어 이전 명령어(indirect control transfer instruction)들을 추론하기 위해 복수의 전략들이 사용된다. (1) 인덱스 메모리 우회(indexed memory indirect)의 경우, 기본 블록과 그것의 선행자 기본 블록들의 명령어들은 점프 테이블이 인덱스되고 있는지를 결정하기 위해 검사된다. 이는 인덱스 바운드 체크 코드(index bounds check code)에 의해 인식된다. 테이블의 주소를 결정하려는 시도도 또한 이루어진다(예컨대, 액세스는 절대 또는 IP 상대적인 베이스 주소를 사용할 수 있다). 사용되고 있는 테이블 주소, 인덱스 범위, 및 액세스 크기를 알기 때문에, 테이블이 읽기 전용 메모리에 있는지를 보기 위한 점검이 이루어지고, 만일 그렇다면 타겟 주소들을 얻기 위해 그 내용이 읽혀진다. 이 접근법은 스위치 테이블에 대해 보통의 컴파일러들에 의해 발생되는 코드 관용구들(code idioms)을 핸들링할 수 있다. (2) 레지스터 우회의 경우, 레지스터를 정의하는 것의 위치를 찾기 위해 가능하면 선행자 기본 블록들로 돌아가서 바로 앞에 선행하는 명령어들이 검사된다. 만일 그것이 로드 명령어라면, 위의 (1)이 점검될 수 있고, 만일 그렇지 않으면 타겟들은 DISASSEMBLE-BB 함수에 의해 사용되는 것과 동일한 방법으로 결정된다. 이 접근법은 간접 호출들에 대해 보통의 컴파일러들에 의해 발생되는 코드 관용구들을 핸들링할 수 있다. 만일 브랜치 타겟 정보를 직접적으로 제공하는 HPM이 이용가능하다면, 이 전략 대신에 사용될 수 있다.

MARK-UNPATCHABLE 함수는 명령어를 패치하는 것이 오버래핑 명령어들에 포함된 바이트들을 훼손하지 않는 것을 보장한다. MARK-UNPATCHABLE 함수는 매핑을 워크(walk)하고 다른 엔트리들과 오버랩되는 엔트리들과 관련된 모든 기본 블록들을 패치불가능한(unpatchable) 것으로서 마킹함으로써 이를 수행한다. 엔트리의 존재는 그것이 지원되지 않거나 점프-프롬-핫 한계치를 초과함으로 인해 탐색되지 않는 것으로 판명되더라도 그 주소로의 제어 이전이 검출되었다는 것을 의미하기 때문에, 제어 이전은 다른 엔트리가 기본 블록인지 여부에 관계없이 수행된다. 부모 엔트리 정보는 오버래핑 엔트리들을 검출하는 데 사용된다.

이외에도, MARK-UNPATCHABLE 함수는 만일 기본 블록들이 실행된 것으로 알려져 있는 기본 블록들로부터 도달가능하지 않으면 그것들을 패치불가능한 것으로 마킹함으로써 사실상 명령어들이 아닌 바이트들을 패치하는 것을 방지한다. 이 동작은 제어 흐름 그래프를 샘플들을 갖는 명령어들을 포함하는 기본 블록들로부터 시작하여 워크하고, 계승자 제어 흐름 에지들을 뒤따른다. 앞서 논의된 바와 같이, 호출 명령어 폴-스루 제어 흐름 에지들은 호출이 실제로 리턴하지 않을 수 있기 때문에 무시된다. 이 동작은 DISASSEMBLE-BB가 샘플을 갖는 첫번째 명령어에 대한 정보를 제공함으로써 그리고 다른 엔트리 동작들이 명령어 경계 정보로부터 도움을 받아 그것을 유지함으로써 보조받는다. 제어 흐름 그래프를 워크하기 전에, 이 동작은 기본 블록들을 3개의 세트들, 즉 샘플을 가지지 않는 기본 블록들인 비실행되는(unexecuted) 것들, 샘플을 가지지만 첫번째 명령어에서는 가지지 않는 부분적인(partial) 것들, 및 첫번째 명령어에서 샘플을 가지는 실행되는(executed) 것들로 파티셔닝된다. 부분적인 기본 블록들과 실행되는 기본 블록들은 모두 작업 리스트에 추가된다. 그런 다음, 작업 리스트 상의 기본 블록들은 이 동작에 의해 처리된다. 각 기본 블록은 그것을 작업 리스트로부터 제거하고 그것의 계승자 제어 흐름 에지들을 뒤따름으로써 처리된다. 호출 제어 흐름 에지를 뒤따를 때, 해당 호출 타겟 기본 블록은 타겟으로서 사용된다. 하지만, 호출 폴-스루 제어 흐름 에지는 호출이 실제로 리턴하지 않을 수 있기 때문에 무시된다. 다른 제어 흐름 에지들의 경우, 타겟은 직접적으로 사용된다. 만일 타겟이 비실행되는 세트에 있다면, 그것은 본래 존재하지 않았기 때문에 실행되는 세트로 이동되고 작업 리스트에 추가되며; 만일 부분적인 세트에 있다면, 첫번째 명령어가 이제 일부 다른 기본 블록의 실행되는 명령어로부터 도달가능한 것으로 알려져 있기 때문에 실행되는 세트로 이동되며; 만일 그렇지 않으면, 그것은 이미 실행되는 세트에 있고 무시될 수 있다. 작업 리스트가 비어 있게 되면, (1) 비실행되는 세트에 남아 있는 모든 기본 블록들은 패치불가능한 것으로 마킹되고, (2) 샘플을 갖는 첫번째 명령어 직전에 부분적인 세트의 모든 기본 블록들은 스플릿되고 상부에 해당하는 기본 블록은 패치불가능한 것으로 마킹된다.

일단 핫 코드 발견이 완료되면 매핑 구조는 삭제된다.

도 11은 코드 파티셔닝 동작의 수도 코드 표현을 도시한 것이다. 더욱 구체적으로, DBR(130)은 이제 기본 블록들의 세트 뿐만 아니라 DBR이 그것들 사이에서 발견한 제어 흐름 에지들로 구성되는 하나의 큰 수퍼-영역을 가진다. 이 수퍼-영역은 핫 코드의 독립 영역들에 해당하는 다중 독립 연결 서브그래프들을 포함하는 경향이 있을 것이다. 서브그래프들 사이에 제어 흐름이 존재하지 않기 때문에, DBR(130)은 독립적으로 서브그래프들에 대한 대체 코드를 발생시킬 수 잇으며, 이는 더욱 효율적일 것이다.

서브그래프들을 독립적으로 처리하는 것은 각 핫 영역에 대한 코드 지역성의 이점이 있다. 이 처리는 또한 각 핫 영역이 별도로 관리될 수 있도록 한다(예컨대, 더 이상 핫이지 않은 영역들은 언패치하지만 핫으로 남아 있는 것들은 유지함). 뿐만 아니라, 코드 발견은 서로 다른 루틴들에 대한 코드가 디스조인트 서브그래프들에 있도록 의도적으로 호출들을 표현한다. 인라이너 추단법(inliner heuristics)은 만일 그것들이 루틴들 상에서 독립적으로 동작할 수 있다면 수행할 인라이닝의 양을 추정하는 데 있어서 더욱 효과적이다.

이런 이유들 때문에, DBR(130)은 코드를 디스조인트 서브그래프들로 파티셔닝하고 각각을 별도의 수퍼-영역에 위치시킨다. 전통적인 컴파일러 분석을 지원하기 위해(예컨대, 지배자(dominator) 및 후-지배자(post-dominator)와 루프 네스팅(loop nesting)), DBR(130)은 또한 모든 기본 블록들이 시작 기본 블록으로부터 도달가능하고 모든 기본 블록들이 꼬리 기본 블록에 도달할 수 있는 것을 보장하는 데 필요한 엔트리 및 엑시트 에지를 추가한다.

더욱 구체적으로, PARTITION-CODE 함수는 먼저 SEPARATE-CONNECTED-COMPONENTS 함수를 호출하며, 이 함수는 시드 기본 블록으로부터 선행자 및 계승자 제어 흐름 에지들 모두를 워크하고, 엔트리 및 엑시트 제어 흐름 에지들을 무시함으로써 각각의 연결 성분(connected component, CC)들을 식별한다. 각각의 연결 성분은 그 자신의 수퍼-영역으로 이동되고, 관련된 엔트리 및 엑시트 에지들은 그 수퍼-영역의 시작 및 꼬리 기본 블록들에 부착된다.

그런 다음, CONNECT-TERMINALS 함수가 각 수퍼-영역에서 호출된다. 이 함수는 먼저 수퍼-영역의 강한 연결 성분(strongly connected component, SCC)들을 계산한다. 이들은 최대 서브그래프들로서, 그 안의 모든 기본 블록은 모든 다른 기본 블록으로 도달가능하다. 시작/꼬리 기본 블록들은 선행자/계승자 제어 흐름 에지들을 가지지 않아서 다른 기본 블록들과 순환을 이룰 수 없기 때문에 항상 그들 자신의 강한 연결 성분에 있다. 강한 연결 성분들은 최대이기 때문에, 강한 연결 성분들 사이의 제어 흐름은 순환을 형성할 수 없다. 그러므로, 모든 다른 강한 연결 성분들은 그것들로부터 도달가능하기 때문에 오직 또 다른 강한 연결 성분으로부터의 제어 흐름 에지를 가지지 않는 강한 연결 성분들만이 시작 기본 블록에 연결될 필요가 있다(그것들은 순환을 형성하기 때문에 그것들의 임의의 기본 블록은 그럴 것이다). 유사하게, 엑시트 에지들은 또 다른 강한 연결 성분에 대한 제어 흐름 에지를 가지지 않는 강한 연결 성분들에만 추가될 필요가 있다(다시, 임의의 기본 블록은 그럴 것이다). 엔트리 및 엑시트 에지들의 사전 존재는 추가적인 것들을 추가하는 필요성을 제거할 것이다. 엑시트 에지는 만일 클라이언트 코드가 실제로 무한 루프를 가지는 경우에만 추가될 필요가 있기 때문에 엑시트 에지를 추가하는 것은 드물다.

오직 제어 이전 명령어들만이 제어 흐름 에지 샘플 카운트를 설정하는 데 사용될 수 있는 HPM 샘플 정보를 제공한다. 비-제어 이전 명령어로 끝나는 임의의 기본 블록은 샘플 카운트를 가지지 않는 폴-스루-온리 제어 흐름 에지를 가질 것이다. COMPUTE-FALL-THROUGH-ONLY 함수는 이들 카운트의 근사값을 계산한다. 이 함수는 폴-스루-온리 체인들이 먼저 오직 폴-스루-온리 제어 흐름 에지들만을 포함하는 최대 경로들을 포함하게 만든다. 만일 오버래핑 코드가 다중 기본 블록들을 동일한 기본 블록으로 폴-스루하게 한다면, 그것은 무작위로 하나를 선택하고 다른 것들은 무시한다. 더 높은 주소를 갖는 명령어로 폴-스루하는 것만이 가능하기 때문에 순환은 있을 수 없다.

시작 기본 블록을 선행자로서 가지지 않는 모든 체인들의 경우, COMPUTE-FALL-THROUGH-ONLY 함수는 선행자 제어 흐름 에지 카운트들을 함께 더하고 비-폴-스루 계승자 제어 흐름 에지 카운트들을 빼서 폴-스루 제어 흐름 에지 카운트를 순방향 추론하는 것을 스캔한다. 최대 체인의 상단에서 시작함으로써, COMPUTE-FALL-THROUGH-ONLY 함수는 임의의 폴-스루 선행자가 그 샘플 카운트를 사용하기 전에 계산되도록 하였을 것이라고 결정한다.

COMPUTE-FALL-THROUGH-ONLY 함수는 수도 엔트리 에지들에 대한 샘플 카운트들을 가지지 않기 때문에, 이것들에서 시작하는 체인들은 순방향 스캔될 수 없다. 그 대신에, COMPUTE-FALL-THROUGH-ONLY 함수는 계승자 제어 흐름 에지 카운트들을 함께 더하고 비-폴-스루 선행자 제어 흐름 에지 카운트들을 빼서 선행자 폴-스루 제어 흐름 에지 카운트를 추론하도록 이들 체인들을 역방향 스캔한다. 다시, 계승자 폴-스루 카운트들이 사용되기 전에 계산된다. 엔트리 및 엑시트 에지 모두를 가지는 체인들은 있을 것 같지 않으며 COMPUTE-FALL-THROUGH-ONLY 함수는 단순히 수도-제어 흐름 에지들이 0의 카운트를 가진다고 가정한다.

INLINE-HOT-CALLS 함수는 호출 기본 블록들을 호출의 타켓인 기본 블록들의 클론(clone)으로 연결한다. 클로닝(cloning)은 관련 호출 타겟 기본 블록에서 시작하며, 리턴 기본 블록들까지 제어 흐름을 뒤따르며, 이는 다시 본래의 호출 기본 블록의 계승자에 연결된다. 수퍼-영역들은 오직 핫 코드만을 포함하기 때문에, 인라이너는 실제로 핫 경로들을 부분적 인라이닝하는 것을 수행하고 있다. 호출된 루틴에서 임의의 엑시트 에지들은 클로닝된 기본 블록들에서 엑시트 에지들이 된다.

INLINE-HOT-CALLS 함수는 본래의 호출 및 인라인된 리턴 명령어들을 인라인된 호출 리턴 주소 변환에 의해 나중에 확장되는 수도-명령어들로 대체한다. 이 동작은 호출 방법의 최적화를 허용한다. 최악의 경우, 엑시트 에지가 실제 리턴 명령어를 실행하는 클라이언트 코드로 리턴하는 경우 인라인된 호출 리턴 주소 변환은 본래의 클라이언트 주소를 스택에 푸시한다. 인라인된 호출 리턴 주소 변환이 리턴 주소를 푸시하는 것을 방지할 수 있더라도(엑시트 에지들이 없기 때문에), 인라인된 호출 리턴 주소 변환이 클로닝된 기본 블록들에서 모든 스택 액세스 옵셋들을 적절히 변경할 수 있지 않는다면 인라인된 호출 리턴 주소 변환은 여전히 스택 상의 주소를 위한 갭을 남겨둘 필요가 있을 수 있다.

클로닝된 기본 블록들은 사실상 특정 호출지(call site)에 대한 본래의 루틴의 특화(specialization)이다. 그러므로, 만일 코드가 그 호출지로부터 호출되었을 때 코드가 실제로 루틴을 실행하고 있었다면 클라이언트 코드가 그것들로 직접적으로 들어가는 것만이 합법적(legal)일 것이다. 패치 포인트들은 호출 컨텍스트에 대해 전혀 모르고 오직 대체 코드에서 단일 방향으로 갈 수 있기 때문에, 가장 안전한 것은 인라인된 기본 블록을 절대 패치하지 않는 것이다. 이는 모든 인라인된 기본 블록들을 패치불가능한 것으로 마킹함으로써 이루어진다. 유의할 점은 인라이닝은 본래의 루틴 기본 블록들을 삭제하지 않는다는 것이다. 그러므로, 패치 포인트들을 가지는 루틴의 대체 코드 버전이 발생되고, 만일 인라인된 클론이 빠져나간다면 들어갈 수 있는 것은 이런 비-특화된 버전이다.

간접 호출들의 경우, 핫 코드 발견은 주지의 타겟들에 대해 다중 제어 흐름 에지들을 생성한다. INLINE-HOT-CALLS 함수는 이들 각각을 정상적으로 인라이닝하며, 호출을 수도-호출-디스패치(pseudo-call-dispatch) 명령어로 변환한다. 이것은 간접 제어 흐름 변환의 일부로서 직렬 테스트들로 변환된다.

INLINE-HOT-CALLS 함수는 모든 수퍼-영역들에 대한 호출 그래프를 계산하고 다음의 요건들을 모두 만족하는 호출지들을 반복적으로 인라이닝한다. (1) 호출 기본 블록은 핫이다. INLINE-HOT-CALLS 함수는 어느 호출들이 핫이고 인라이닝할 가치가 있는지를 결정하기 위해 샘플 카운트들을 사용하며, 인라이닝되지 않은 호출들을 포함하는 루틴을 인라이닝할 수 있다(아마도 그것들은 콜드 경로들 상에 있었기 때문에). (2) 호출 기본 블록을 포함하는 루틴은 여전히 예산 추단법(budget heuristic) 내에 있다. INLINE-HOT-CALLS 함수는 그것이 수행하고 있는 코드 확장량을 모니터링하고 코드 지역성의 이점에 불리하게 영향을 주거나 공유 메모리를 오버플로우시킬 과도한 코드 이용을 방지한다. 별도 루틴들에 대한 코드를 그들 자신의 개개의 수퍼-영역들에 가지는 것은 이것을 용이하게 만들고, 각 수퍼-영역은 그 자신의 예산을 가진다. (3) 호출 타겟 기본 블록은 알려져 있다(이것은 간접 호출의 언노운 타겟이 아니다). (4) 호출 타겟 기본 블록으로부터 적어도 하나의 리턴 기본 블록으로의 경로가 존재한다. 만일 INLINE-HOT-CALLS 함수가 클로닝된 기본 블록들을 역으로 호출함수로 연결할 수 있어서 DBR(130)이 완전한 프로시저간 루프들을 발견할 수 있는 경우에만 인라인닝할 가치가 있다. 다중 엔트리들을 갖는 루틴들이 지원되면, 각 호출 타겟 기본 블록은 그 자신의 리턴 기본 블록들의 세트를 가질 수 있다. (5) 호출된 루틴은 핫 호출지를 가지지 않는다. 잎(leaf)들로부터 위쪽으로 호출지들을 처리하는 것은 루틴이 이미 그 자신에 대해 인라이닝이 수행되게 한 후에만 인라이닝되는 것을 보장한다. 그것은 또한 호출 그래프에서 순환을 형성하는 (아마도 상호) 회귀적 루틴(recursive routine)들을 인라이닝하는 것을 방지하고 따라서 결코 잎들이 될 수 없다.

INLINE-HOT-CALLS 함수는 클로닝된 기본 블록과 제어 흐름 에지들 상의 카운트들을 호출에 대한 카운트들과 일치하도록 스케일링한다. 이는 반드시 이 호출지의 실제 거동을 반영하는 클로닝된 카운트들을 만들진 않더라도, 근사치이다. INLINE-HOT-CALLS 함수는 또한 본래의 기본 블록과 제어 흐름 에지들로부터 클로닝된 카운트들을 빼서 결과적인 카운트들은 더 이상 이 호출지에 의해 실행되지 않는 다는 것을 반영한다.

푸시된 리턴 주소는 대체 코드 내에 있을 것이기 때문에 클라이언트 프로세스는 대체 코드의 호출 명령어를 절대 실행해서는 안 된다. 대체 코드 내에 리턴 주소를 푸시하는 것은 2개의 문제들을 가지는데, 클라이언트 프로그램이 핸들러를 선택할 때 리턴 주소를 검사하는 예외 메커니즘들을 사용하고 있을 수 있다는 것과; 대체 코드가 언패치될 수 있으며, 모든 푸시된 리턴 주소를 찾아서 업데이트하기가 어려울 것이라는 것이다. 이를 방지하기 위해, INLINE-HOT-CALLS 함수는 인라이닝되지 않은 모든 호출 기본 블록들을 삭제한다. 호출 기본 블록의 선행자 제어 흐름 에지들은 엑시트 에지들을 꼬리 기본 블록에 연결함으로써 엑시트 에지들이 된다. INLINE-HOT-CALLS 함수는 임의의 필수적인 엔트리 제어 흐름 에지들을 호출 기본 블록의 계승자 기본 블록들에 추가하기 위해 CONNECT-TERMINALS 함수를 호출한다. 이는 수퍼-영역들이 다중 연결 성분들을 가지도록 할 수 있지만, 이는 PRUNE-CODE 함수에 의해 수행되는 파티셔닝에 의해 핸들링된다.

도 12는 패치 포인트 선택 동작의 수도 코드 표현을 도시한 것이다. 일정한 유형의 프로세스 아키텍처들의 아키텍처 제한사항들로 인해, 클라이언트 코드의 모든 명령어가 패치하기에 적합한 것이 아닐 수 있다. 예를 들어, x86 프로세서 아키텍처에서, 5-바이트 브랜치 명령어는 1-바이트의 오피코드(opcode)에 이어 4-바이트 옵셋(offset)을 포함하며, 이는 대체 코드로 이전하는 데 사용된다. 그러므로, 오로지 5 바이트보다 더 큰 클라이언트 명령어들만이 패치될 수 있다. 더 작은 명령어를 패치하는 것은 하나 이상의 명령어를 덮어쓰기(overwrite)할 수 있고, 만일 그 다음 명령어들 중 하나가 브랜치의 타겟이었다면, 패치는 프로그램을 훼손할 것이다.

추가적인 어려움은 다중-프로세서 아키텍처 상의 또 다른 프로세서에 의해 동시에 실행되고 있을 수 있는 코드를 안전하게 수정하는 능력이다. 이 문제는 또한 관리되는 코드 시스템들(managed code systems)(예컨대, 자바 가상 머신)에서 마주칠 수 있으며 해결책이 이용가능하지만, 그것들은 패치될 수 있는 클라이언트 명령어들 상에 추가적인 제한사항들을 부가할 수 있다. AMD x86 프로세서에 대한 해결책은 (1) 만일 바이트들이 얼라인(align)된 8 바이트 경계를 스팬(span)하지 않는다면 그것들을 단지 쓰는(write) 것이다. 만일 그렇지 않으면 (2) 2 바이트 셀프-브랜치(self-branch) 명령어를 첫번째 2개의 바이트들에 쓰는 것이다. 아토믹(atomic)이 되기 위해, 쓰기가 얼라인된 8 바이트 경계를 스팬해서는 안 된다. (3) 모든 프로세서들이 본래의 명령어를 펫치(fetch)하고 있을 수 있기 때문에 모든 프로세서들이 이전의 쓰기 전에 시작된 명령어 펫치들을 완료하였다는 것을 보장하기 위해 기다린다. (4) 그 다음 3 바이트(옵셋의 마지막 3 바이트)를 쓴다. (5) 브랜치 오피코드와 옵셋의 첫번째 바이트로 처음 2 바이트를 다시 쓴다. 이해될 수 있는 바와 같이, AMD 유형의 x86 아키텍처 상에서 클라이언트 명령어들이 패치될 수 있는 추가적인 제한사항들을 부가한다. 다른 아키텍처들은 유사한 제한사항들을 가질 수 있다.

핫 코드는 한번 진입되면 여러번 실행되는 루프들을 포함한다고 관찰된다. 루프들은 클 수 있고 많은 루틴들에 걸쳐 스팬할 수 있지만, 직선형 코드는 그 자체로 실행하기에 너무 오래 걸리고 따라서 핫일 수 없다. DBR(130) 발견 동작은 수퍼-영역들을 생성하므로(이는 임의의 제어 흐름을 허용함), 완전한 루프들을 식별할 수 있다. 하지만, DBR(130)은 오직 핫 코드를 탐색하기 때문에, 루프들내에서 가끔 실행되는 것이지만 수퍼-영역들의 일부가 아니고 클라이언트 코드로 다시 빠져나오는 경로들이 있을 수 있다. 만일 이러한 경로가 루프의 조기 반복(early iteration)에서 실행되는 경향이 있다면, 제어는 클라이언트 코드로 리턴될 수 있으며, 제어는 다음번에 핫 수퍼-영역이 진입될 때까지 남아 있을 것이다. 따라서, DBR(130)이 성공적으로 루프들의 핫 경로를 식별하더라도, DBR(130)은 모든 루프 반복들에 대한 수퍼-영역에 남아 있지 않을 수 있다. 이런 문제에 대한 해결책은 루프 보디에 패치들을 위치시키려는 시도이고, 따라서 만일 이러한 패치가 이루어지면, 루프는 그 다음 반복에서 재진입될 것이다. 이러한 패치들을 내곽 루프들에 추가하는 것은 역시 변환들을 제한하는 경향이 있을 수 있다.

마지막으로, 2개의 다른 제약들이 있다. 먼저, 일부 기본 블록들은 절대 패치되어서는 안 된다(즉, 인라이너에 의해 클로닝된 것들과 MARK-UNPATCHABLE 값에 의해 식별되는 것들). 둘째, 패치들을 설치하는 비용은 종종 상대적으로 높으며(페이지 보호를 변경하고 캐쉬들을 플러시(flush)하는 시스템 호출들을 필요로 함), 따라서 DBR(130)이 각 수퍼-영역에서 패치들의 개수를 최소화하는 것이 바람직하다.

PATCH-POINT-SELECTION 함수는 오직 패치될 수 있는 명령어로 시작하는 기준 기본 블록들에 대한 엔트리 에지들을 수정함으로써 이런 난점들을 해결하고, 수퍼-영역의 루프들을 커버하는 패치들의 최소 세트를 발견하는 것을 목표로 한다. 인라이너는 종종 완전한 루틴들이고 패치 제약들에 의해 지장을 받지 않는 수퍼-영역들을 필요로 하기 때문에, DBR(130)은 인라이너 동작 후에 선택을 수행한다.

더욱 구체적으로, PATCH-POINT-SELECTION 함수는 루프 네스트 구조를 계산함으로써 시작한다. 그런 다음, 패치 포인트들의 세트가 결정된다. 이는 기본 블록 단위에서 이루어지며, 패치가능한 기본 블록들의 첫번째 명령어가 실제로 패치가능한지 여부에 민감하지 않다. 그런 다음, PATCH-POINT-SELECTION 함수는 오래된 엔트리 에지들을 제거하고, 패치가능한 함수로 시작하지 않는 임의의 패치 포인트 기본 블록들을 스플릿하고, 그들에 대한 새로운 엔트리 에지들을 생성한다. 이는 단지 그것을 필요로 하는 기본 블록들에 대한 스플릿을 최소화한다.

개념적으로, PATCH-POINT-SELECTION 함수는 완전한 세트의 패치가능한 기본 블록들의 세트를 결정한 다음, 그 세트에서 일부 다른 기본 블록으로부터 패치가능한 임의의 기본 블록을 제거함으로써 이 세트를 최소화한다(양자를 가질 필요는 없음). PATCH-POINT-SELECTION 함수는 도달가능성(reachability)을 결정하기 위해 지배자 관계를 사용할 수 있다. 하지만, 루프들에 대해, 제어 흐름이 그것이 후-지배하는 동일한 루프의 임의의 기본 블록에 도달할 수 있는 것을 루프의 백 에지(back edge)가 보장하기 때문에 PATCH-POINT-SELECTION 함수는 또한 후-지배자 관계를 사용할 수 있다. 내곽 루프에 대해 패치하는 것은 루프들에 대한 변환 잠재성을 제한할 수 있기 때문에 외곽 루프들에서 기본 블록들을 패치하는 것이 바람직하다. 이를 달성하기 위해, PATCH-POINT-SELECTION 함수는 최외곽 루프에서 시작하여 루프 계층구조(loop hierarchy)를 처리한다.

루프 계층구조의 루트 루프(root loop)는 실제로 루프가 아니지만, 네스트된 루프들을 보유하는 플레이스홀더(placeholder)이다. 이는 일련의 루프들로 이어지는 순차적 코드로 시작하는 수퍼-영역들이 표현될 수 있도록 한다. 이런 이유로, PATCH-POINT-SELECTION 함수는 루프 내에 있지 않은 루트 패치들과 루프 내에 있는 루프 패치들을 처리하는 동안 2개의 패치들의 세트를 유지한다. 후-지배자 관계는 루트 패치들을 비교할 때 사용되지 않는다.

PATCHES 함수는 단일 루프에 대한 패치 기본 블록들의 세트를 식별하는 데 사용된다. 그 함수는 먼저 루프 보디에 대한 후보 기본 블록들의 세트를 결정한다. 만일 기본 블록이 패치가능하고 기존 루트(root)나 루프 패치들 중 하나로부터 도달가능하지 않다면 그 기본 블록은 후보이다. 그런 다음, 상기 함수는 각 멤버를 각 다른 멤버와 쌍으로 비교함으로써 이 후보 세트를 최소화하고, 그것이 또 다른 것으로부터 도달가능하다면 하나를 제거한다. 루프의 기본 블록들을 DFS(depth-first search) 순서로 처리함으로써, PATCH-POINT-SELECTION 함수는 상호 도달가능한 루프 보디의 2개의 기본 블록들 중 빠른 것을 선택한다. 이는 둘다 충분할 것이기 때문에 엄격히 필수적이지 않지만, 보다 직관적인 선택이다. 도달가능성은 SUPERCEDES 함수에 의해 결정되며, 이 함수는 지배자 및 후-지배자 관계를 적절히 사용한다.

NESTED-PATCHES 함수는 루프를 그것의 네스트된 루프들과 함께 탑-다운(top-down) 방식으로 처리하기 위해 사용된다. 상기 함수는 그것의 자녀 루프(child loop)들을 조사하기 위해 회기하기 전에 그것의 루프 보디의 기본 블록들을 검사한다. 선택된 임의의 패치들은 임의의 이전 루프 패치들과 유니온(union)되므로, 다른 네스트된 루프들의 후보들을 대신하는 역할을 할 수 있다. NESTED-PATCHES 함수는 네스트된 루프들을 DFS 순으로 처리하므로 이전 루프들이 선호된다. 나중에 네스트된 루프는 이전 네스트된 루프를 대신할 수 있지만, DBR(130)은 오히려 더 이전 것에서 패치를 가지므로 대체 코드는 둘러싸는 패치불가능한 루프의 첫번째 반복에서 진입된다.

PATCH-POINT-SELECTION 함수는 본질적으로 NESTED-PATCHES 함수가 루트 루프에 대해 수행하는 것과 동일한 기능을 수행한다. 상기 함수는 루트 루프에 대해 PATCHES 함수를 사용하지만, 오로지 지배자 관계를 사용하도록 특정하고, 그 결과를 루트 패치들에 놓는다. 그런 다음, 그것은 그것의 네스트된 자녀들에 대해 NESTED-PATCHES 함수를 사용한다. 하지만, 루트 루프는 루프가 아니기 때문에, 상기 함수는 임의의 자녀 루프 패치들을 루트 패치들에 추가한다.

패치 포인트 동작은 외곽 루프들을 패치하는 것을 목표로 하며, 변환에 유익하다. 만일 내곽 루프가 조기 반복에서 엑시트 에지를 따르는 경향이 있다면, 대체 코드를 설치한 후에, 네스트된 루프는 여전히 핫일 것이다. 핫 코드 발견은 이미 설치된 패치들을 지나 탐색하지 않기 때문에, 상기 동작은 단지 네스트된 루프를 찾는 경향이 있을 것이며, 독립적으로 변환될 것이다. 이런 일반적인 접근법은 수정을 쉽게 수정된다(예컨대, 루프가 엑시트 에지들을 가지는지를 보기 위해 분석하고 루프들을 최내곽에서 외곽 방향으로 처리함으로써).

DBR(130) 영역 선택의 마지막 단계에서, PRUNE-CODE 함수는 발견된 코드를 프루닝한다. 하나의 목표는 핫 코드의 수퍼-영역들이 변환으로부터 유익하게 되는 것이다. PRUNE-CODE 함수는 PATCH-POINT-SELECTION 함수가 엔트리 에지들을 변경하였을 때 유발된 임의의 도달불가능한 기본 블록들을 제거한다.

PRUNE-CODE 함수는 또한 단순히 수퍼-영역을 빠져나가지만 핫 기본 블록에 도달할 수 없는 임의의 콜드 꼬리 기본 브록들을 프루닝한다. 이들은 종종 핫 코드 발견의 점프-프롬-핫 조절 메커니즘의 결과이다. 그것들은 핫이 아니고 항상 클라이언트 코드로 다시 이전할 것이기 때문에, 수퍼-영역에 그것들을 포함할 이익이 없고, 대신에, 대체 코드는 단순히 그 이전의 클라이언트 코드로 다시 이전할 수 있다. 이들 기본 블록들을 포함하는 것은 단순히 일꾼 쓰레드에 더 많은 일을 제공하고, 이 코드는 콜드 코드 버퍼에 배치될 것이기 때문에, 그것은 요구되는 추가적인 점프로 이어질 수 있다. 그들은 모든 콜드 기본 블록들을 콜드 세트에 배치하고 모든 핫 기본 블록들을 작업 리스트에 배치함으로써 식별된다. 작업 리스트의 기본 블록들은 모든 그들의 선행자들을 검사함으로써 처리되고, 콜드 세트의 것들은 핫 기본 블록에 도달할 수 있기 때문에 작업 리스트에 추가된다. 콜드 세트에 남아 있는 기본 블록들은 삭제되지만, 콜드 세트에 있지 않은 기본 블록들로부터의 그것들의 선행자 제어 흐름 에지들 중 임의의 것은 엑시트 에지로 변경되고 꼬리 기본 블록에 연결된다.

SEPARATE-CONNECTED-COMPONENTS 함수를 다시 호출하는 것은 인라이너에 의해 이루어지는 제어 흐름 변경들, 패치 포인트 선택, 및 콜드 꼬리 기본 블록 제거로 인해 유익하다. 이는 다시 한번 각 수퍼-영역이 오직 단일 연결 성분만을 포함하는 것을 보장하고, 따라서 다음의 프루닝 동작에 의해 개개로 검사될 것이다.

패치 점프 및 점프 백의 비용이 아마도 임의의 변환 이득들보다 많을 것이기 때문에 다중 반복을 실행하는 루프들을 포함하지 않는 수퍼-영역들은 변환으로부터 혜택이 없을 가능성이 있다. DBR(130)은 루프 네스팅을 조사하고 루프들이 반복되는 평균 횟수를 추정하기 위해 제어 흐름 에지 카운트들을 사용한다. 임계값을 초과하는 임의의 루프들이 없는 그 수퍼-영역들은 삭제된다(이는 전혀 루프들을 가지지 않는 수퍼-영역들을 포함한다). 마지막으로, DBR(130)은 또한 이들 수퍼-영역들이 개선될 수 있는 충분한 코드를 가지지 않을 가능성이 있기 때문에 매우 작은 수퍼-영역들을 삭제한다.

본 발명은 언급된 장점들 뿐만 아니라 그 안에 내재된 다른 장점들을 달성하기에 아주 적합하다. 본 발명이 특정한 실시예들을 참조하여 도시되고, 서술되고, 정의되었지만, 이러한 참조는 본 발명에 대한 제한을 의미하는 것이 아니며, 어떠한 제한도 추론되지 않는다. 본 발명은 형태 및 기능에 있어서 상당한 수정, 변경, 및 균등물들이 가능하며, 이는 당해 기술분야의 통상의 기술자들이라면 고려할 것들이다. 도시되고 서술된 실시예들은 오직 예일 뿐이며, 본 발명의 범위를 완전히 나타내는 것이 아니다.

예를 들어, 다른 프로세서 아키텍처들과 HPM 구현예들이 고려된다는 것은 이해될 것이다.

또한 예를 들어, 위에서 논의된 실시예들은 일정한 작업들을 수행하는 소프트웨어 모듈들을 포함한다. 본 명세서에서 논의되는 소프트웨어 모듈은 스크립트(script), 배치(batch), 또는 다른 실행가능한 파일들을 포함할 수 있다. 소프트웨어 모듈들은 디스크 드라이브와 같은 기계 판독가능한 또는 컴퓨터 판독가능한 저장매체 상에 저장될 수 있다. 본 발명의 한 실시예에 따른 소프트웨어 모듈들을 저장하는 데 사용되는 저장 디바이스들은 예를 들어 자기 플로피 디스크, 하드 디스크, 또는 CD-ROM이나 CD-R과 같은 광학 디스크일 수 있다. 본 발명의 한 실시예에 따른 펌웨어나 하드웨어 모듈들을 저장하는 데 사용되는 저장 디바이스는 또한 반도체 기반의 메모리를 포함할 수 있으며, 이는 영구적으로, 탈착가능하게, 또는 원격으로 마이크로프로세서/메모리 시스템에 연결될 수 있다. 따라서, 상기 모듈들은 모듈의 기능들을 수행하도록 컴퓨터 시스템을 구성하기 위해 컴퓨터 시스템 메모리 내에 저장될 수 있다. 다른 새롭고 다양한 유형의 컴퓨터 판독가능한 저장매체가 본 명세서에서 논의된 모듈들을 저장하는 데 사용될 수 있다. 게다가, 당해 기술분야의 통상의 기술자들은 기능들을 모듈들로 분리하는 것이 예시를 위한 목적이라는 것을 인식할 것이다. 대체가능한 실시예들은 다중 모듈들의 기능들을 단일 모듈로 병합할 수 있고, 또는 모듈들의 기능들을 대체가능하게 성분 분리할 수 있다. 예를 들어, 서브-모듈들을 호출하기 위한 소프트웨어 모듈들은 각 서브-모듈이 그것의 기능을 수행하고 제어를 직접적으로 다른 서브-모듈로 넘겨주도록 성분 분리될 수 있다.

결과적으로, 본 발명은 첨부된 특허청구범위의 사상 및 범위에 의해서만 제한되도록 의도하는 바이며, 특허청구범위는 모든 관점에서 균등물들을 완전히 인지하도록 의도하는 바이다.

Claims (10)

1. 동적 바이너리 재작성기(dynamic binary rewriter, DBR) 프레임워크로서,
   하나 이상의 클라이언트 프로세스들을 샘플링하는 하드웨어 성능 모니터와;
   별도의 프로세스로서 실행되는 DBR 서비스(DBR service)와; 그리고
   상기 하나 이상의 클라이언트 프로세스들 내에서 실행되는 DBR 에이전트(DBR agent)를 포함하며, 상기 DBR 에이전트는 대체 코드(replacement code)를 사용하도록 상기 하나 이상의 클라이언트 프로세스들을 패치하며, 상기 대체 코드는 상기 하나 이상의 클라이언트 프로세스들 각각의 본래의 코드(original code)와 기능적으로 대등한
   DBR 프레임워크.
2. 제1항에 있어서,
   상기 DBR 서비스는 상기 하드웨어 성능 모니터로부터 샘플들을 종합(aggregate)하고, 핫 샘플(hot sample)들 주위의 프로그램 구조를 추론함으로써 영역 선택(region selection)을 수행하고, 상기 선택된 영역들에 대해 영역 변환(region transformation)을 수행하고, 상기 대체 코드를 발생시키는
   DBR 프레임워크.
3. 제1항에 있어서,
   상기 DBR 에이전트는 상기 하나 이상의 클라이언트 프로세스들의 스타트업(startup)시에 상기 하나 이상의 클라이언트 프로세스들 각각의 클라이언트 프로세스 주소 공간(client process address space)으로 자동적으로 로드(load)되고 초기화되며; 그리고
   상기 DBR 에이전트는 대체 코드의 패치(patch) 및 언패치(unpatch)를 수행하고 상기 하나 이상의 클라이언트 프로세스들 상에서 상당한 추가적인 자원 요구사항(resource requirement)들을 부과함이 없이 필수 시스템 라이브러리의 사용에 대한 보고를 수행하는
   DBR 프레임워크.
4. 제1항에 있어서,
   상기 DBR 서비스를 상기 하나 이상의 클라이언트 프로세스들로부터 디커플링(decouple)하는 것은 상기 DBR 서비스가 상기 하나 이상의 클라이언트 프로세스들 내에서 메모리 사용을 최소화하고 공유 라이브러리들을 피하면서 만일 이용가능하다면 하나 이상의 별도의 코어들을 이용하여 상기 하나 이상의 클라이언트 프로세스들과 동시에 실행될 수 있게 하며; 그리고
   상기 DBR 서비스를 상기 하나 이상의 클라이언트 프로세스로부터 디커플링하는 것은 상기 DBR에 의해 사용되는 시스템 자원들이 조정(coordinate)될 수 있도록 상기 DBR 서비스가 다중 클라이언트 프로세스들을 관리할 수 있게 하는
   DBR 프레임워크.
5. 제1항에 있어서,
   상기 DBR 서비스를 상기 하나 이상의 클라이언트 프로세스들로부터 디커플링하는 것은 상기 DBR 서비스가 관리되고 있는 상기 클라이언트 프로세스들의 스냅샷(snapshot)을 연속적으로 취하는 것과 필요하다면 새로운 대체들을 제거하거나 생성하는 것을 구동할 수 있게 하는
   DBR 프레임워크.
6. 제1항에 있어서,
   상기 DBR 서비스는 DBR 제어 쓰레드(DBR control thread)를 포함하고, 상기 DBR 제어 쓰레드는 상기 DBR 에이전트와의 통신을 관리하고 상기 DBR 서비스의 양상(aspect)들을 조정하는
   DBR 프레임워크.
7. 제1항에 있어서,
   상기 DBR 서비스는 하나 이상의 일꾼 쓰레드(worker thread)들을 포함하며, 각 일꾼 쓰레드는 클라이언트 프로세스에 대해 영역 선택 동작, 영역 변환 동작, 및 대체 코드 발생 동작을 수행하는
   DBR 프레임워크.
8. 제1항에 있어서,
   상기 DBR 서비스는 상기 하나 이상의 클라이언트 프로세스들에서 핫 코드를 결정하기 위한 시스템을 더 포함하고, 상기 시스템은
   핫 코드 발견(hot code discovery) 동작을 수행하기 위한 명령어들과;
   코드 파티셔닝(code partitioning) 동작을 수행하기 위한 명령어들과;
   폴-스루-온리 계산(fall-through-only computation) 동작을 수행하기 위한 명령어들과;
   핫 호출 인라이닝(hot call inlining) 동작을 수행하기 위한 명령어들과;
   패치 포인트 선택(patch point selection) 동작을 수행하기 위한 명령어들과; 그리고
   코드 프루닝(code pruning) 동작을 수행하기 위한 명령어들을 포함하는
   DBR 프레임워크.
9. 제8항에 있어서,
   상기 핫 코드 발견 동작은 어떠한 정적 프로그램 정보(static program information)도 필요로 함이 없이 자주 실행되는 것으로 알려진 주소들에서 시작하여 순방향(forward)으로 클라이언트 프로세스 코드를 디스어셈블(disassemble)하고; 그리고
   임의적 제어 흐름(arbitrary control flow)을 포함하는 제어 흐름 그래프(control flow graph)를 제공하도록 상기 클라이언트 프로세스의 제어 흐름을 따르는
   DBR 프레임워크.
10. 제9항에 있어서,
    상기 핫 코드 발견 동작은 명령어 경계(instruction boundary)들과 오버래핑 코드 시퀀스(overlapping code sequence)들에 대한 정보를 기록하는 엔트리 매핑 및 위치 구조(entry mapping and position structure)를 사용하여 오버래핑 명령어들을 검출하며; 그리고
    오버래핑 명령어들은 가변길이 명령어들을 갖는 아키텍처 상에서 실행될 때 그리고 호출 규약(calling convention)이 절대 리턴(return)하지 않는 호출들을 가질 수 있을 때 발생할 수 있는
    DBR 프레임워크

Images