KR101224788B1 - 비동기적 프로그램 흐름의 모델링을 갖는 소프트웨어 도구 - Google Patents

Abstract

프로그램 내에서의 비동기적 전송을 모델링하는 데 사용되는 모든 가능한 엣지보다 적은 엣지를 갖는 흐름도를 사용하여 프로그램의 중간 표현을 형성하는 컴파일러가 개시된다. 흐름도는 다단계로 형성된다. 한 단계에서, 흐름도는 비동기적 전송을 모델링하지 않고 형성된다. 나중의 단계들에서, 비동기적 전송의 효과의 표현이 선택적으로 부가된다. 나중의 단계들의 일부로서, 가능한 비동기적 전송을 모델링하는 엣지들은, 피보호 영역 밖에서 활성(live)인 변수들의 피보호 영역에서의 정의 이후에 흐름도에 부가된다. 변수의 활성 상태(live-ness)의 수정된 정의가 비동기적 전송 이후에, 피보호 영역을 비롯한 임의의 영역에서의 변수의 사용을 구체화하는 데 사용된다. 피보호 영역으로부터의 엣지는 또한 정의된 변수의 유일한 사용이 핸들러에서 있는 경우 모델에 부가된다.

컴파일러, 비동기적 전송, 변수 정의, 핸들러, try 보디, 예외 핸들러

Description

비동기적 프로그램 흐름의 모델링을 갖는 소프트웨어 도구{SOFTWARE TOOL WITH MODELING OF ASYNCHRONOUS PROGRAM FLOW}

도 1a는 종래 기술의 고레벨 프로그래밍 언어로 작성된 프로그램을 나타낸 도면.

도 1b는 도 1a의 종래 기술의 프로그램의 동작의 그래픽 표현을 나타낸 도면.

도 1c는 도 1a의 종래 기술의 프로그램의 동작을 나타내는 흐름도의 그래픽 표현을 나타낸 도면.

도 2는 본 발명의 일 실시예에 따른 흐름도의 그래픽 표현을 나타낸 도면.

도 3은 본 발명의 실시예를 이해하는 데 유용한 흐름도의 그래픽 표현을 나타낸 도면.

도 4는 본 발명의 실시예를 이해하는 데 유용한 흐름도의 그래픽 표현을 나타낸 도면.

도 5는 본 발명의 실시예를 이해하는 데 유용한 흐름도의 텍스트 표현을 나타낸 도면.

도 6a는 본 발명의 실시예를 이해하는 데 유용한 흐름도의 텍스트 표현을 나타낸 도면.

도 6b는 도 6a의 텍스트 표현을 이해하는 데 유용한 흐름도의 그래픽 표현을 나타낸 도면.

도 7은 본 발명의 일 실시예에 따른 프로그램의 프로세싱을 나타낸 플로우차트.

도 8a는 본 발명의 일 실시예에 따른 프로그램의 프로세싱을 나타낸 플로우차트.

도 8b는 본 발명의 일 실시예에 따른 프로그램의 프로세싱을 나타낸 플로우차트.

<도면의 주요 부분에 대한 부호의 설명>

140: try 보디

150: 영역

162, 164, 168, 172: 블록

186, 190: 비동기적 엣지

260: 흐름도

본 발명은 일반적으로 컴퓨터 소프트웨어 시스템에 관한 것으로서, 보다 구체적으로는 실행에 앞서 컴퓨터 프로그램을 프로세싱하는 컴퓨터 소프트웨어 시스템에 관한 것이다.

컴퓨터 프로그램은 종종 일련의 명령어로서 작성된다. 어떤 명령어는 프로그램이 실행될 때 수행되는 동작을 지정할 수 있다. 다른 명령어는 다른 명령이 실행되는 순서 또는 조건을 지정함으로써 프로그램 흐름을 제어할 수 있다. 또다른 명령어는 프로그램에서의 변수를 나타내는 정보가 프로그램을 실행하는 프로세서에 부속된 메모리에 어떻게 저장되는지 등의 프로그램의 실행의 파라미터를 지정할 수 있다.

고레벨 프로그래밍 언어에서, 명령어는 반드시 소프트웨어가 실행될 플랫폼에 의해 실행될 수 있는 명령어와 일대일 관계로 대응하지 않아도 된다. 오히려, 명령어는 사람이 이해할 수 있는 형태로 되어 있을 수 있다. 이러한 형태의 프로그램은 먼저 프로세싱되어 특정의 플랫폼에 의해 실행되기에 적당한 형태로 되어야만 한다. 다른 프로세서 또는 다른 오퍼레이팅 시스템을 갖는 플랫폼은 프로그램이 적절한 실행을 위해 다르게 표현되도록 요구할 수 있다.

소프트웨어 도구는 보통 프로그램을 특정의 플랫폼에 의해 실행될 수 있는 형태로 변환하는 데 사용된다. 도구의 예로는 컴파일러가 있다. 단순히 각각의 고레벨 명령어를 프로세서가 실행할 수 있는 일련의 명령어로 표현하는 것 이외에, 이들 도구는 프로그램을 최적화하거나 다른 방식으로 그를 프로세싱할 수 있다. 프로그램이 실행을 위해 준비되고 있을 때 프로그램 상에서 수행될 수 있는 프로세싱의 예는 데드 코드(dead code) 제거, 스케쥴링, 코드 이동(code motion) 및 공통 부분식 제거(common sub-expression elimination)가 있다.

프로그램의 프로세싱 시에, 소프트웨어 도구는 종종 코드를 중간 표현으로 변환한다. 중간 표현은 프로그램이 실행될 때 수행되어야만 하는 동작의 알맞은 표현을 제공한다. 또한, 중간 표현은 프로그램이 실행되는 동안 변수들이 사용되는 프로그램의 일부분에 관한 정보를 비롯하여, 정보를 저장하는 데 사용되어질 그 변수들에 관한 정보를 제공한다. 중간 표현은 또한 동작들 간의 프로그램 흐름에 관한 정보를 제공한다.

종종, 중간 표현은 프로그램의 흐름을 "흐름도(flow graph)"로서 기술한다. 흐름도는 블록 및 엣지(edge)를 포함한다. 각각의 블록은 소정의 순서로 실행되어질 명령어의 모음을 나타내며, 따라서 블록에 대한 하나의 시작점 및 하나의 종료점이 있다. 흐름도에서, 엣지는 블록들이 실행되는 순서를 나타내기 위해 블록들을 상호 연결시킨다. 흐름도는 프로그램이 실행될 때 취해질 수 있는 블록을 통과하는 모든 가능한 경로를 나타내는 엣지를 포함한다. 다수의 경로가 각각의 블록에 연결될 수 있다.

프로그램 흐름 및 메모리 요구사항에 관한 정보는 프로그램을 여러 방식으로 프로세싱하는 데 사용될 수 있다. 이 정보는 특정의 플랫폼 상에서 실행하기 위한 프로그램을 구현하는 명령어를 준비하는 데 사용될 수 있거나 플랫폼 독립적인 방식으로 최적화를 행하는 데 사용될 수 있다.

도 1a는 C# 고레벨 프로그래밍 언어로 작성된 프로그램(100)을 나타낸 것이다. 프로그램(100)은 명령어(112, 114) 등의 일련의 명령어를 포함한다. 도 1a의 예에서, 명령어(112, 114)는 변수 Y의 "정의"이다. 본 명세서에서 사용되는 바와 같이, 용어 "정의"는 일반적으로 변수와 연관된 정보를 생성, 수정 또는 다른 방식 으로 변경할 수 있는 임의의 명령어를 말한다.

프로그램(100)은 또한 try 보디(try body)의 시작을 정의하는 명령어(120)를 포함한다. 중괄호(121)는 명령어(120)로 시작하는 try 보디의 끝을 정의한다. try 보디는 또한 때로는 "코드의 피보호 영역(protected region of code)"이라고 부른다.

try 보디는 때로는 "보호 영역(protecting region)" 또는 "핸들러(handler)"라고도 하는 하나 이상의 코드의 보호 영역과 관련하여 동작할 수 있다. 여기에, 2개의 핸들러, 예외(exception) 핸들러 및 "finally" 핸들러가 예시되어 있다. 예외 핸들러는 또한 "catch 핸들러"라고도 한다. 예외 핸들러는 명령어(122)로 시작하고 중괄호(123)로 끝난다. 프로그램(100)은 또한 try 보디와 연관된 finally 핸들러를 갖는다. finally 핸들러는 명령어(124)로 시작하고 중괄호(125)로 끝난다.

프로그램(100)은 또한 try 보디 밖에 위치하는 명령어(130) 등의 명령어를 포함한다.

핸들러의 동작은 프로그램(100)의 실행을 예시하는 도 1b에 나타내어져 있다. 이 예에서, try 보디(140)는 프로그램(100) 내의 첫번째 실행가능 명령어를 포함한다. 정상 동작 시에, try 보디(140)가 먼저 실행되고, try 보디(140) 내의 명령어들이 그 명령어들에 의해 지정된 순서로 실행된다.

finally 핸들러(144) 내의 명령어들은 try 보디(140), 예외 핸들러(142) 및 finally 핸들러(144)로 이루어진 try 영역 내의 마지막 명령어들로서 실행된다. 정상 실행 시에, try 보디(140) 내의 명령어들의 실행이 완료되면, 실행은 finally 핸들러(144)로 넘어간다.

finally 핸들러(144) 내의 명령어들이 실행된 후에, try 영역(140) 이후의 프로그램(100) 내의 명령어들이 실행된다. 여기서, 그 명령어들은 영역(150)에 있다.

예외 핸들러(142) 내의 명령어들은 try 보디(140) 내의 명령어들이 실행되는 동안에 예외가 발생하는 경우에만 실행된다. 예외 조건은 프로그램(100)에서 특수 예외 명령어들의 실행에 의해 생성될 수 있다. 그렇지만, 대부분의 경우, 예외 조건은 프로그램(100)을 실행하는 플랫폼에 대해 그 플랫폼에게는 부적법한 동작인 것으로 생각되는 동작을 수행하라고 명령하는 프로그램(100) 내의 명령어의 실행에 의해 야기된다. 부적법한 동작의 예로는 영으로 나누는 것과, 플랫폼에 대해 시스템에 설치되어 있지도 않고 오퍼레이팅 시스템에 의해 예비되어 있지도 않은 주소의 메모리에 액세스하도록 지시하는 명령어가 있다.

예외 핸들러(142)는 비동기적으로 실행되는 것으로 생각될 수 있다. 본 명세서에서 사용되는 바와 같이, 용어 "비동기적"은 결과적으로 제어의 이전을 야기하도록 하기 위한 프로그램 내의 명령어가 아닌 프로그램 실행 동안에 조건에 응답하여 발생하는 예외 등의 이벤트를 기술한다. finally 핸들러(144)도 또한 예외 핸들러(142) 이후에 실행될 수 있기 때문에 비동기적으로 실행되는 것으로 생각될 수 있다.

도 1c는 try 보디(140)로부터 예외 핸들러(142)까지의 가능한 경로를 보다 상세히 나타내고, 따라서 비동기적 이벤트로부터 일어날 수 있는 문제를 나타내는 흐름도이다. try 영역(140) 내의 명령어들 각각은 162, 164, 166, 168, 170 또는 172 등의 블록으로 나타내어져 있다. 엣지(178) 등의 엣지는 블록들 간의 정상적인 흐름을 나타낸다. 엣지(180A, 180B, 182, 184, 186, 188, 190, 192)는 비동기적 엣지를 나타낸다. 비동기적 엣지는 try 보디(140) 내의 임의의 명령어의 실행이 프로그램 흐름을 예외 핸들러(142)로 넘어가도록 야기할 수 있을 가능성을 나타낸다. 엣지(180A)는 try 보디(140) 내의 임의의 명령어의 실행에 앞서 에러가 발생할 수 있을 가능성을 나타낸다. 엣지(180B)는 예외 핸들러(142)의 실행의 종료 시에 발생하는 제어의 이전을 나타낸다.

어떤 종래 기술의 소프트웨어 도구는 try 영역 - 도 1c에 나타낸 바와 같이 핸들러 영역(142)으로 흐름이 넘어갈 수 있는 모든 가능한 명령어로부터의 엣지를 부가함으로써 이 try 영역으로부터 제어의 비동기적 이전이 가능함 - 을 비롯하여 프로그램의 중간 표현을 형성한다. try 영역 내의 모든 명령어로부터의 엣지를 부가하는 것은 프로그램의 불완전한 표현을 프로세싱한 결과로 일어날 수 있는 에러를 피하기 위해 사용되어 왔다.

그렇지만, 도 1c에 나타낸 "모든 가능한 엣지(all possible edges)" 방법을 사용하여 비동기적 엣지를 부가하는 것의 단점은 그 결과 흐름도가 복잡하다는 것이다. 프로그램(100)은 비교적 간단한 프로그램을 나타낸다. 상업적으로 중요한 프로그램은 예시된 것보다 더욱 많은 명령어를 포함할 수 있다. 게다가, 프로그램은 다수의 핸들러가 각각의 영역과 연관되어 있는 다수의 try 영역을 포함할 수 있다. 게다가, try 영역은 다른 try 영역 내에 내포될 수 있다. 다른 복잡한 것으 로서, 핸들러의 실행 후에 흐름이 try 보디의 끝으로 복귀할 필요가 없다. 핸들러는 프로그램 흐름을 프로그램 내의 임의의 장소로 또는 프로그램 내의 다수의 장소 중 어느 곳으로라도 바꿀 수 있으며, 그 특정의 장소는 런타임시 조건에 의해 결정된다. 그 결과, 모든 가능한 비동기적 엣지를 흐름도에 부가하는 것은 흐름도를 아주 복잡하게 만든다. 이러한 흐름도에 기초하여 프로그램을 프로세싱하는 것은 따라서 상당한 시간 또는 컴퓨터 자원을 필요로 할 수 있다.

어떤 종래 기술의 소프트웨어 도구에서, 모든 가능한 비동기적 엣지를 부가한 결과로 인한 복잡성은 비동기적 엣지를 갖지 않는 흐름도를 생성하는 것에 의해 회피된다. 그렇지만, 보상하기 위해, 이들 흐름도에 기초하여 프로그램을 프로세싱하는 도구는 모든 가능한 흐름 경로의 정확한 표현에 의존하는 try 영역 내의 명령어들에 대해 동작을 수행하지 않는다. 이와 같이 프로그램을 프로세싱하는 것이 보다 빠르거나 간단할 수 있지만, 소프트웨어 도구의 이점이 달성되지 않는다.

소프트웨어 도구에 의한 프로그램의 프로세싱을 용이하게 해주기 위해 제어의 비동기적 이전을 비롯하여 프로그램을 표현하는 방법을 갖는 것이 바람직하다.

이 특허 출원은 try 보디 영역에서 핸들러로의 이전에서 발생하는 것 등의 비동기적 흐름을 포함하는 프로그램을 모델링하는 데 사용되는 프로그램의 중간 표현에 대해 기술한다. 프로그램 내에서의 비동기적 이전의 효과의 간단화된 표현이 프로그램 프로세싱의 복잡도를 감소시키기 위해 사용되지만 그 결과의 정확도는 유지된다. 이 중간 표현은 여러 방식으로 사용될 수 있다.

한 측면에서, 본 발명은 제1 영역 - 이 영역으로부터 프로그램 실행이 비동기적으로 이전될 수 있음 - 및 제1 영역으로부터의 프로그램의 비동기적 이전 이후에 실행될 수 있는 제2 영역을 갖는 프로그램을 프로세싱하는 방법에 관한 것이다. 이 방법은 적어도 제1 영역의 표현을 형성하는 단계를 포함하며, 이 표현은 복수의 제1 타입 구문(construct)을 포함한다. 제1 타입 구문 각각은 하나 이상의 동작을 나타낸다. 이 표현은 적어도 하나의 제2 타입 구문을 포함하며, 제2 타입 구문 각각은 제1 타입의 구문들 간의 실행 흐름을 나타낸다. 변수의 정의를 포함하는 제1 영역 내의 적어도 하나의 제1 타입 구문에 대해, 제1 타입 구문으로부터의 흐름을 나타내는 제2 타입 구문이, 변수가 제2 영역에서 사용되는지 여부에 기초하여, 상기 표현에 선택적으로 부가된다.

다른 측면에서, 본 발명은 프로그램을 프로세싱하는 컴퓨터 판독가능 매체에 관한 것이다. 프로그램은 제1 영역, 제2 영역 및 제3 영역에 명령어를 갖는다. 프로그램 실행은 제1 영역으로부터 제3 영역으로 비동기적으로 이전될 수 있고, 제2 영역 내의 명령어는 제3 영역 내의 명령어 이후에 실행된다. 컴퓨터 판독가능 매체는 제1 영역 및 제2 영역을 포함하는 표현을 형성하는 컴퓨터 실행가능 명령어를 가지며, 이 표현은 복수의 명령어 및 이 복수의 명령어의 실행 순서를 나타내는 정보를 포함한다. 컴퓨터 실행가능 명령어는 또한, 변수의 정의를 포함하는 제1 영역 내의 적어도 하나의 명령어에 대해, 명령어가 제2 영역에서 사용되는 변수를 정의할 때 표시를 상기 표현에 선택적으로 부가한다.

다른 측면에서, 본 발명은 제1 영역, 제2 영역 및 제3 영역을 갖는 프로그램을 프로세싱하는 도구에 관한 것이다. 프로그램 실행은 제1 영역으로부터 제3 영역으로 비동기적으로 이전될 수 있고, 제2 영역은 제1 영역 밖으로의 프로그램의 비동기적 이전 이후에 실행될 수 있다. 도구는 제1 영역 및 제2 영역을 포함하는 표현을 형성하도록 구성된 모듈을 포함한다. 이 표현은 복수의 블록 및 복수의 엣지를 포함한다. 도구는 또한 상기 표현에 엣지를 선택적으로 부가하도록 구성된 모듈을 포함한다. 이 모듈은 변수의 정의를 포함하는 제1 영역 내의 블록을 프로세싱하고 또 변수가 제2 영역에서 사용되는지 여부에 기초하여 블록으로부터의 엣지를 상기 표현에 선택적으로 부가하도록 구성되어 있다.

첨부 도면은 축척에 따라 도시되어 있지 않다. 도면에서, 여러 도면에 예시된 각각의 동일한 또는 거의 동일한 구성요소는 유사한 참조 번호로 나타내어져 있다. 명료함을 위해, 모든 도면에서 모든 구성요소에 도면 부호가 부기되어 있지 않을 수 있다.

본 발명은 비동기적 이전의 효과의 표시를 포함하는 소프트웨어의 중간 표현을 생성함으로써 종래 기술의 한계를 극복하였다. 중간 표현은 모든 가능한 비동기적 엣지보다 적은 엣지를 포함할 수 있으며, 따라서 프로그램의 중간 표현 및 그에 기초한 임의의 프로세싱을 단순화시키고 또 중간 표현을 사용하여 프로그램을 프로세싱하는 도구의 정확한 동작을 보장해준다. 비동기적 이전의 효과는 하나 이상의 방식으로 나타내어질 수 있다. 어떤 실시예에서, 비동기적 이전의 효과의 표시는 비동기적 이전을 직접 나타내는 엣지 형태이다. 다른 실시예에서, 비동기적 이전의 효과는 프로그램에서 사용되는 변수와 관련하여 저장된 정보에 의해 나타내어진다. 정보는 심볼 테이블 또는 중간 표현 내의 의사 명령어(pseudoinstruction)에 저장될 수 있다. 동일한 중간 표현에서 비동기적 이전의 효과를 나타내는 데 여러 형태가 사용될 수 있다.

본 발명은 먼저 예로서 흐름도를 포함한 중간 표현을 사용하여 기술된다. 선택된 비동기적 이전의 효과는 흐름도 내의 엣지로서 나타내어져 있다. 다른 비동기적 이전의 효과는 중간 표현과 연관된 심볼 테이블 내의 주석으로 나타내어진다. 이러한 표현은 기존의 소프트웨어 도구와 호환되는 이점을 갖지만 임의의 적당한 표현이 사용될 수 있다.

중간 표현은 프로그램의 동기적 동작을 전통적인 방식으로 나타낼 수 있다. 한 실시예에서, 프로그램의 모든 부분은 현재 알려져 있거나 이후에 개발된 종래의 기술을 사용하여 흐름도로서 모델링된다. 핸들러로의 비동기적 흐름은 처음에 흐름도에 모델링되어 있지 않다. 중간 표현은 이어서 비동기적 이전의 효과를 나타내기 위해 확장 또는 다른 방식으로 수정될 수 있다.

도 2는 도 1c에 나타낸 것과 동일한 프로그램의 흐름도(260)를 그래픽적으로 나타낸 것이다. 흐름도(260)는 비동기적 엣지(180A, 180B, 186, 190)를 포함한다. 가능한 비동기적 엣지 모두가 이 표현에 포함되어 있는 것은 아니다. 비동기적 엣지(186, 190)가 흐름도에 포함되어 있는 이유는 이들이 전통적인 소프트웨어 도구가 부정확한 또는 의도하지 않은 결과를 가져오지 않고 흐름도를 사용하여 동작될 수 있게 해주기 때문이다. 도 1c의 "모든 가능한 엣지" 흐름도에 표시된 엣지 (182, 184, 188, 192)가 포함되어 있지 않은 이유는 이들이 전통적인 소프트웨어 도구가 흐름도(260)를 사용하여 의도대로 동작하는 데 필요하지 않기 때문이다.

엣지(186, 190)가 흐름도(260)에 포함시키기 위해 선택된 이유는 이들이 변수를 정의하는 블록 - 이 변수는 그 블록을 포함하는 try 영역 밖에서 사용됨 - 을 뒤따라 오기 때문이다. 이 예에서, 변수 Y는 영역(150)에서 사용되고 비동기적 엣지는 Y를 정의하는 각각의 블록 이후에 부가된다.

역으로, 블록(162, 164, 168, 172) 이후에는 어떤 비동기적 엣지도 포함되어 있지 않다. 이들 블록이 A, B, X 및 Z 등의 변수의 정의를 포함하고 있지만, 이들 변수 중 어느 것도 try 보디(140) 밖에서 사용되지 않는다. 프로그램(100)의 실행 동안에 일어나는 어떤 일련의 조건 하에서, 이들 명령어는 영역(150) 내의 명령어의 실행에 앞서 실행될 수 있다. 다른 조건 하에서, 비동기적 이전으로 인해, 그 명령어는 실행되지 않을 수 있다. 그럼에도 불구하고, 프로그램 흐름이 비동기적 이벤트에 의해 try 보디(140) 밖으로 나가는 경우 어떤 명령어도 그가 정의하는 변수를 사용하지 않기 때문에, 흐름도가 그 명령어 이후에 비동기적 이전이 있을 가능성을 나타내지 않더라도 어떤 에러도 유입되지 않는다. 따라서, 비동기적 엣지(182, 184, 188)가 흐름도(260)에 포함되어 있지 않다.

영역 밖에서 어느 변수가 사용되는지를 식별하는 것은 소프트웨어 도구에서 전통적으로 수행되는 기능이다. 영역 밖에서 사용되는 변수는 때로는 그 영역 "밖에서 활성"(live-out)인 것으로 기술된다. 변수가 영역 밖에서 사용되는지 여부를 판정하는 알고리즘은 "활성 상태(live-ness)" 알고리즘이라고 한다. 변수가 try 영역 밖에서 활성인지 여부를 판정하는 어떤 프로세스 - 현재 알려져 있는 것이거나 이후에 개발된 것인지에 상관없이- 라도 사용될 수 있다.

게다가, 변수의 활성 상태는 임의의 편리한 방식으로 표현될 수 있다. 예를 들어, 심볼 테이블이 하나 이상의 비트 벡터(bit vector)를 사용하여 각각의 try 영역에 대해 작성될 수 있으며, 각각의 비트 벡터는 그 영역 내의 변수들이 가지고 있거나 그렇지 않을 수 있는 속성(property)을 기술한다. 하나의 이러한 비트 벡터가 변수들이 밖에서 활성(live-out)인지의 표시를 저장할 수 있다. 비트 벡터를 사용하면 프로세싱 시간을 감소시킬 수 있다. 예를 들어, 각각의 변수는 비트 벡터 내의 특정의 비트 위치로 해싱될 수 있는 정수값을 할당받을 수 있다. 각각의 변수에 대해 활성 상태 계산이 수행될 때, 변수가 밖에서 활성인지 여부에 기초하여 대응하는 비트가 세트(set) 또는 클리어(clear)될 수 있다. 변수를 정의하는 각각의 명령어에 대해, 심볼 테이블 내의 비트 벡터로의 간단한 액세스는 비동기적 엣지가 그 정의 이후에 부가되어야만 하는지를 나타낸다.

중간 표현에 엣지를 부가하는 상기 방법은 어떤 시나리오에서 모든 비동기적 이전의 효과를 적절히 표현하지는 않는다. 도 3은 비동기적 이전의 추가의 표현이 요망될 수 있는 시나리오를 나타낸 것이다.

도 3은 흐름도(360)를 나타낸 것이다. 흐름도(360)에 예시된 프로그램은 try 보디(340), 예외 핸들러(342), finally 핸들러(344), 및 영역(350)으로 나타낸 try 영역 밖의 다른 코드를 포함한다. 도 3에 나타낸 프로그램은 예외 핸들러(342)의 실행 이후에 실행이 try 보디(340) 내의 지점으로 복귀한다는 점에서 프로 그램(100)(도 1)과 다르다. 구체적으로 말하면, 실행은 블록(340B)으로 복귀한다.

이 예에서, 블록(340B)은 예외 핸들러(342)의 실행 이후의 진입점 이외의 진입점을 갖지 않는 코드를 포함한다. 블록(340B) 내의 코드는 또한 전통적인 활성 상태를 사용할 때 try 영역(340) 밖에서 활성인 것으로 간주되지 않는 변수 X를 사용한다. 따라서, try 영역 밖의 변수의 활성 상태에 기초하여 엣지를 단순히 부가하는 것으로는 X의 정의 이후의 엣지가 흐름도에 포함되지 않는다. 그렇지만, 엣지를 흐름도에 포함하지 않으면 중간 표현에 기초한 프로그램의 부정확한 프로세싱을 야기할 수 있다. 예를 들어, 표현은 어떤 명령어도 명령어(168)에서의 X의 정의를 "사용(consume)"하지 않으며 따라서 명령어(168)가 코드 밖에서 "최적화"될 수 있게 됨을 암시할 수 있다. 부정확한 동작이 중간 표현을 사용하지 못하도록 하기 위해, 변수가 try 영역 밖에서 활성이 아닐지라도 그 변수가 비동기적 이전 이후에만 실행되는 try 영역의 일부분을 형성하는 블록에서 사용되는 경우, 비동기적 엣지가 그 변수의 정의 이후에 부가된다. 여기서, 흐름도(360)는 이를 위한 엣지(380)를 포함한다.

중간 표현을 형성하기 위해 프로그램을 프로세싱함에 있어서, 비동기적 이전 이후에만 실행되는 try 보디 내의 블록에서 사용되는 변수의 정의 이후에 엣지를 부가하기 위한 다수의 실시예가 가능하다. 일 실시예에서, 밖에서 활성인 변수의 정의 이후에 또 핸들러 내에서 사용되는 변수의 정의 이후에 비동기적 엣지를 부가하기 위해 별도의 프로세싱 단계가 사용될 수 있다.

다른 대안에서, 밖에서 활성(live-out)의 정의가 비동기적 이전 이후에만 실 행되는 try 보디의 블록에서 사용되는 변수를 포괄하도록 수정될 수 있다. 밖에서 활성의 수정된 정의를 사용하면 심볼 테이블에서 사용되는 비트 벡터가 비동기적 엣지가 부가되어야만 하는 변수들의 전체 리스트를 포함하도록 밖에서 활성인 변수를 표현할 수 있다. 전술한 바와 같이, 이 비트 벡터가 결정되면, 중간 표현에 대해 한번의 패스(pass)가 행해져 밖에서 활성인 비트 벡터에 표시되어 있는 변수의 각각의 정의 이후에 엣지를 부가할 수 있다.

어떤 실시예에서, 밖에서 활성인 비트 벡터는 2번 이상의 패스로 형성될 수 있다. 첫번째 패스에서, 전통적인 밖에서 활성인 계산은 try 보디 상에서 수행될 수 있다. 두번째 패스에서, 비동기적 이전 이후에 실행되는 try 보디의 블록에서 사용되는 변수는 밖에서 활성인 비트 벡터에 포함될 수 있다. 다른 대안에서, 밖에서 활성인 변수를 식별하는 수정된 알고리즘은 try 영역 밖에서 사용되고 또 비동기적 이전 이후에만 실행되는 try 영역의 블록에서 사용되는 변수를 표시하는 비트 벡터가 한번의 패스로 형성되도록 사용될 수 있다. 밖에서 활성에 대한 수정된 정의를 사용하여 비트 벡터를 작성하는 데 사용될 수 있는 프로그램이 이하에 기술된다.

도 3은 또한 try 영역 밖에서 활성인 변수들에 대한 비동기적 엣지를 단순히 부가하는 것이 원하는 결과를 가져오지 않을 수 있는 다른 가능한 시나리오를 나타낸 것이다. 이 예에서, Y의 값은 밖에서 활성이 아니지만, 예외 핸들러(342)에서사용된다. 상기한 바와 같이 형성된 중간 표현은 Y를 사용하는 핸들러(342) 내의 명령어가 try 보디(340) 내의 Y의 정의 이후에 실행될 수 있음을 표시하는 흐름 경 로를 생성하는 엣지를 포함하지 않는다. 그 결과, 중간 표현에 대해 동작하는 도구는 런타임 시에 예외 핸들러(342) 내의 코드에 의해 액세스될 수 없는 변수 Y에 대한 메모리 구조를 설정할 수 있다.

예를 들어, 변수 Y는 레지스터에 또는 런타임 시에 동적으로 결정되는 스택 내의 메모리 장소에 저장될 수 있다. 레지스터에 저장되는 변수는 예외 핸들러의 실행 시에 변경될 수 있으며, 이는 Y의 값을 변경시키는 원하지 않은 효과를 가지게 된다. 이와 마찬가지로, 스택 상의 정보에 액세스하는 데 사용되는 스택 포인터 및 다른 구문은 프로그램 실행이 try 보디 영역으로부터 예외 핸들러로 옮겨갈 때 변경될 수 있다. 이와 반대로, try 보디 영역 밖에서 사용되는 변수는 일반적으로 프로그램 흐름이 try 보디 영역(340)을 벗어난 후에 그 변수가 액세스될 수 있도록 저장된다.

모든 가능한 비동기적 엣지를 포함하지 않는 중간 표현은 변수 Y의 정의와 예외 핸들러(342)에서의 그의 사용 간의 흐름 경로를 표시하지 않을 수 있다. 표시하지 않는 경우, 중간 표현에 대해 동작하는 전통적인 도구가 변수 Y의 값이 예외 핸들러(342) 내의 코드로부터 액세스불가능한 try 보디에서 사용되도록 변수 Y에 대한 스토리지를 할당할 수 있다.

변수 Y의 각각의 정의 이후에 엣지를 포함함으로써 의도하지 않은 결과가 회피될 수 있으며, 이는 중간 표현을 프로세싱하는 임의의 도구에, 비동기적 이전으로 인해 흐름이 try 보디를 벗어난 이후에 변수가 사용될 수 있음을 알려주게 된다. 보다 일반적으로, 비동기적 엣지는 관련 핸들러 내에서 사용되는 변수의 try 보디에서의 각각의 정의 이후에 흐름도에 부가될 수 있다.

흐름도에 엣지를 부가하는 것의 다른 대안으로서, 변수가 핸들러에서 사용될 때 비동기적 이전의 효과는 중간 표현에서 변수 Y가 예외 핸들러(342) 내의 코드로부터 액세스될 수 있도록 메모리에 저장될 필요가 있다는 표시에 의해 표현될 수 있다. 일 실시예에서, 이 결과는 프로그램의 전통적인 중간 표현에서 이용가능한 구문을 사용함으로써 달성된다.

특정의 예로서, try 영역(340)에 대해 작성된 심볼 테이블에서 주석 첨부가 행해질 수 있다. 심볼 테이블은 변수 Y가 핸들러에서 사용됨을 표시하기 위해 주석 첨부될 수 있다. 변수에 대한 스토리지를 할당하기 위해 중간 표현을 사용하는 도구는 이러한 표시를 인식하고 또 변수가 예외 핸들러로 인도할 수 있는 임의의 경로를 따라 스택으로 "호밍(home)"되어야만 하도록 구성될 수 있다. 스택으로 호밍된 변수는 그 변수가 생성되는 곳인, 스택에 관련한 특정의 장소를 갖게 된다. 변수를 스택으로 호밍하는 것은 그 변수에 액세스하는 예외 핸들러(342)에 대한 코드가 생성될 수 있게 해준다.

try 보디 내에 정의되고 밖에서 활성은 아니지만 try 보디에 첨부된 핸들러 내에서 사용되는 각각의 변수에 대해 유사한 주석 첨부가 행해질 수 있다. 이와 관련하여, 용어 "사용(use)"은 변수가 정의되거나 사용되는 것을 의미할 수 있음을 의미한다.

심볼 테이블에서의 주석 첨부는 임의의 적당한 형태로 행해질 수 있다. 심볼 테이블이 다른 목적을 위해 변수가 스택으로 호밍되어야만 함을 표시하기 위해 사용되는 비트 벡터 등의 데이터 구조를 포함하는 경우, 어느 변수가 스택으로 호밍되어야 하는지를 표시하기 위해 그 데이터 구조에 값들이 기입될 수 있다.

다른 목적을 위해 이러한 데이터 구조가 사용되지 않는 경우, 심볼 테이블은 어느 변수가 핸들러 내에서 사용되는지를 표시하기 위해 비트 벡터 또는 다른 데이터 구조로 작성될 수 있다. 중간 표현으로부터 기계 실행가능 코드를 생성하는 컴파일러나 다른 도구는 각각의 이러한 변수에 대해, 변수를 스택으로 호밍하는 코드를 생성하거나 변수가 그 변수를 사용하는 try 영역과 연관된 핸들러에서 액세스가능하게 되도록 다른 방식으로 변수를 위한 스토리지를 할당하게 된다.

도 4는 프로그램의 중간 표현을 형성하는 프로세스의 실시예에서 사용되는 흐름도를 보다 상세히 나타낸 것이다. 도 4는 try 영역, 예외 핸들러(142) 및 finally 핸들러(144)를 포함한 흐름도(460)를 나타낸 것이다. 흐름도는 상기한 프로세스에 따라 작성된다.

흐름도는 먼저 동기적 흐름만을 표현하는 흐름도를 형성하는 것에 의해 생성된다. 엣지들이 비동기적 이전을 표현하기 위해 선택적으로 부가된다. 엣지(482)는 try 보디 내용을 래핑하기 위해 부가된다. 이 엣지(482)는 try 보디 내에 드물게 행해지는 도달불가능한 블록이 없도록 방지하는 것을 간단화시키기 위해 포함된다. 엣지(484)는 try 보디 끝을 래핑한다. 이 엣지(484)는 try 보디에 도달하는 모든 것에 대한 완전한 흐름을 보장해준다. 기술된 실시예에서, 이들 엣지는 변수가 어디에서 정의 또는 사용되는지에 상관없이 핸들러를 포함하는 모든 try 보디에 대한 중간 표현에 포함되어 있다.

엣지(486₁, 486₂)는 밖에서 활성인 변수의 정의 이후에 부가되는 엣지를 나타낸다. 엣지(488₁, 488₂, 488₃)는 핸들러(142)의 실행 이후의 가능한 복귀 경로를 나타낸다. 엣지(488₄)는 finally 핸들러(144)로부터의 복귀를 나타낸다. 이들 흐름 경로의 표현은 대부분의 소프트웨어 도구에 의한 중간 표현의 정확한 프로세싱을 위해 바람직하다.

그렇지만, 중간 표현에서 간단화는 "싱크 블록(sink block)"을 생성하여 핸들러로부터의/로의 흐름을 모델링함으로써 행해질 수 있다. 싱크 블록은 try 영역으로부터의 비동기적 이전의 효과를 표현하기 위해 흐름도에 부가된 모든 엣지의 목적지일 수 있다. 핸들러의 실행 이후에 실행이 흘러갈 수 있는 각각의 가능한 곳으로의 엣지는 싱크 블록으로부터 나올 수 있다.

도 4의 예에서, 영역(410)은 try 영역(140)에 대한 핸들러 모두를 포함한다. 영역(410)은 싱크 블록으로서 표현될 수 있다. 영역(410) 내의 임의의 위치에서 종료되는 엣지는 싱크 블록에서 종료되는 것으로 나타내어질 수 있다. 예를 들어, 엣지(484, 486₁, 486₂)는 싱크 블록에서 종료되는 것으로 표시될 수 있다. 영역(410) 내의 임의의 지점에서 나오는 엣지는 싱크 블록으로부터 나오는 것으로 나타내어질 수 있다. 예를 들어, 엣지(488₁, 488₂, 488₃, 488₄)는 싱크 블록으로부터 나오는 것으로 나타내어질 수 있다.

싱크 블록에서 종료하지도 나오지도 않는 비동기적 엣지는 종료하거나 나오는 엣지로 표현될 수 있다. 예를 들어, 엣지(482)는 제거되고 싱크 블록으로 들어가는 엣지 및 싱크 블록에서 나오고 영역(150)에서 종료하는 엣지로 대체될 수 있다. 그렇지만, 엣지(484)는 엣지(482)와 동일한 지점에서 시작한다. 엣지(484)는 이미 엣지(482)를 대체하게 되는 싱크 블록으로의 엣지를 표현한다. 이와 유사하게, 엣지(488₄)는 이미 싱크 블록과 엣지(484)의 종료점에 있다. 동일한 2개의 지점 간에 다수의 엣지를 포함할 필요가 없으며, 따라서 도 4의 예에서, 싱크 블록이 사용되는 경우 엣지(482)를 따른 흐름을 표현하기 위해 부가의 엣지가 부가될 필요가 없다.

도 2, 도 3 및 도4에서, 흐름도의 블록들은 심볼에 의해 표현되고, 엣지들은 심볼들을 연결시키는 화살표를 갖는 라인에 의해 표현된다. 이러한 그래픽 표현은 사람이 흐름도를 개념화(human conceptualization of the flow graph)하기 위한 보조물이다. 소프트웨어 도구는 흐름도의 그래픽 표현을 생성할 필요가 없다. 흐름도 내의 각각의 블록은 컴퓨터 프로그램에서의 명령어와 유사한, 파일에서의 텍스트 라인으로서 표현될 수 있다. 블록들은 라벨로 식별될 수 있고, 엣지들은 라벨로의 브랜치를 표시하는 텍스트 라인에 의해 표현될 수 있다. 그렇지만, 흐름도를 표현하기 위해 선택된 특정의 형태가 본 발명에 중요한 것은 아니며 임의의 적당한 표현이 사용될 수 있다.

도 5는 컴퓨터 파일 내의 텍스트로서 구현된 흐름도를 나타낸 것이다. 파일 내의 라인들은 중간 명령어를 포함한다. 중간 명령어는 고레벨 프로그램에서 또는 중간 표현으로부터 생성된 기계어 프로그램에서 사용된 명령어와 일대일 대응 관계를 가질 필요가 없다. 양호하게는, 명령어는 중간 표현이 고레벨 프로그램으로부터 용이하게 생성될 수 있게 해주고 또 기계 레벨 명령어가 중간 표현으로부터 생성될 수 있게 해주는 형태이다. 이러한 중간 명령어 세트는 알려져 있으며, 현재 알려져 있거나 이후에 개발된 것이든 임의의 적당한 중간 명령어 세트가 사용될 수 있다.

도 5의 실시예에서, 엣지는 프로그램 제어를 이전하는 명령어에 의해 표현된다. 예를 들어, 명령어(512)는 명령어에서 식별된 라벨로의 제어의 이전을 신호하는 구(phrase) "GOTO"를 포함한다. 여기에서, 라벨은 L42로서 표시되어 있다. 라벨(L42)은 finally 핸들러 내의 명령어보다 또한 이어서 try 보디의 명령어의 실행의 완료 시에 실행되는 영역(150)(도 2) 내의 명령어보다 선행한다.

흐름도 내의 블록들은 도 5에서 제어를 이전하는 또는 다른 방식으로 영역의 끝을 신호하는 명령어에 의해 인터럽트되지 않는 순차적 명령어에 의해 나타내어져 있다.

모든 중간 명령어가 기계 레벨 명령어로 번역되는 것은 아니다. 의사 명령어(pseudoinstruction)라고 하는 어떤 명령어는 다른 명령어가 어떻게 프로세싱되는지를 표시하기 위해 사용된다. 예를 들어, 명령어(514)는 try 영역의 시작을 식별해준다. 명령어(516)는 try 보디 영역의 끝을 식별해준다. 명령어(518)는 try 영역의 끝을 식별해준다.

의사 명령어는 또한 비동기적 이전의 효과를 표현하는 데 사용된다. 명령어 (520, 522, 524)는 코드 OPONERROR 및 라벨을 포함하는 의사 명령어이다. 이들 의사 명령어는 GOTO 명령어(512)와 유사하지만, 코드 OPONERROR는 라벨로의 조건부, 비동기적 이전을 나타낸다. 명령어(520, 522)는 도 4에 도시한 엣지(482, 484)로 나타낸 것과 유사한 효과를 나타낸다. 엣지(524)는 도 4에서 엣지(488₃)로 나타낸 것과 유사한 효과를 나타낸다. 라벨(L1, L2, L3)은 명령어(520, 522, 524)에 대한 목적지를 제공하기 위해 중간 표현에 부가된다.

명령어(530, 532)는 또한 비동기적 이전의 효과를 표현하기 위해 사용된다. 이들은 OPONERROR 코드와 그 뒤에 오는 라벨을 포함한다. 명령어(530, 532)는 도 4에 도시된 엣지(486₁, 486₂)로 나타낸 것과 유사한 효과를 나타낸다.

전술한 바와 같이, 중간 표현은 어느 변수가 영역 밖에서 활성인지 또는 어느 변수가 스택으로 호밍되어야만 하는지 등의 프로그램에 관한 추가의 정보를 제공하기 위해 심볼 테이블 또는 다른 데이터 구조를 포함할 수 있다. 그렇지만, 의사 명령어도 역시 이 목적을 위해 사용될 수 있다.

명령어(540)는 의사 명령어이다. 도 3과 관련하여 전술한 바와 같이, 변수가 try 보디 밖에서 다른 방식으로 사용되지 않는 경우, 중간 표현은 변수가 try 보디와 연관된 핸들러에서 사용되는지 여부를 나타낸다. 명령어(540)는 코드, OPSIDEEFFECT 및 변수 이름을 포함한다. 이 명령어는 그 명령어 내에 포함된 변수가 핸들러 내에서 사용되는지를 나타내는 데 사용된다. 본 명세서에서 사용되는 바와 같이, OPSIDEEFFECT Y 형태의 의사 명령어는 그 변수가 핸들러 내에서 사용됨 을 나타낸다. Y = OPSIDEEFFECT 형태에서, 의사 명령어는 변수가 핸들러에서 정의됨을 나타낸다. 이러한 명령어는 예를 들어 그 표현으로부터 형성된 기계 코드 프로그램을 실행하는 프로세서에서 변수와 연관된 정보의 저장에 영향을 주는 데 사용될 수 있다. 게다가, 이 명령어는 도구가 중간 표현에 대해 동작하는 방식에 영향을 주는 데 사용될 수 있다. 예를 들어, 어떤 도구는 "가비지 컬렉션(garbage collection)"을 수행하며, 이는 프로그램의 프로세싱 전체에 걸쳐, 도구가 더 이상 필요로 하지 않는 변수의 저장을 위해 할당된 메모리 장소를 식별한다는 것을 의미한다. 이 메모리는 이어서 정보의 추가의 저장을 위해 이용가능한 것으로 표시될 수 있다. 이와 마찬가지로, 어떤 도구는 "데드 코드(dead code)" 제거를 수행할 수 있다. 이들 도구는 차후에 사용되지 않는 변수를 정의하는 코드를 식별 및 제거하기 위해 중간 표현을 프로세싱한다. 종래의 가비지 컬렉션 또는 데드 코드 제거가 중간 표현에 기초하여 수행되는 경우, 의사 명령어의 사용은 필요한 코드가 제거되지 않도록 하거나 변수를 위해 필요한 저장 장소가 오버라이트되지 않도록 한다.

이와 같이 변수의 사용을 표현하는 것은 또한 기계 종속적인 전역적 최적화(machine dependent global optimization)가 중간 표현에 대해 수행될 수 있게 해준다. 예를 들어, 어떤 플랫폼은 예외를 다르게 취급할 수 있다. 어떤 플랫폼에서, 핸들러는 별도의 함수로서 실행될 수 있다. 예외가 발생할 때, 프로세서는 프로세서 내의 레지스터의 내용을 예측불가능하게 오버라이트할 수 있다. 따라서, 이러한 플랫폼에 대한 코드를 생성하는 도구는 예외 핸들러로 하여금 레지스터를 try 보디 내에 정의된 변수의 값으로 재로드하도록 하는 이러한 의사 명령에 응답하여 예외 핸들러의 일부로서 명령어를 생성할 수 있다. 의사 명령어는 예외 핸들러가 적절히 실행되도록 이 코드가 작성되어야만 한다는 것을 나타낸다.

중간 표현(510)에 의해 예시된 실시예에서, 예외 핸들러는 550에서의 명령어로 표현되고 finally 핸들러는 552에서의 명령어로 표현된다. 예외 핸들러 및 finally 핸들러는 핸들러가 활성(active)인 메소드에 대한 EXIT 명령어(560)의 끝에 첨부되어 있다. 핸들러는 서로소 함수(disjoint function)로서 프로세싱될 수 있다. 다른 실시예에서, 핸들러 내의 특정의 코드는 추가의 프로세싱에서 단순히 무시될 수 있다.

도 6a는 중간 표현(610)의 대체 실시예를 나타낸 것이다. 중간 표현(610)은 중간 표현(510)(도 5)와 동일한 프로그램을 나타낸다. 싱크 블록(640)을 갖는 중간 표현(610)은 형성된다. 싱크 블록(410)(도 4)과 유사하게, 싱크 블록(640)은 비동기적 이전을 표현하기 위해 부가된 엣지들에 대한 종료점이다. 싱크 블록(640)의 시작은 여기에서 라벨(L2)로 표현되어 있다.

명령어(620)는 라벨(L2)에서의 싱크 블록의 시작을 가리키는 OPONERROR 의사 명령어이다. 명령어(620)는 명령어(520, 522)(도 5) 둘다의 효과를 모델링한다. 이와 유사하게, 명령어(630, 632)는 라벨(L2)을 가리키는 OPONERROR 의사 명령어이다. 명령어(630, 632)는 각각 명령어(530, 532)의 효과를 모델링한다.

싱크 블록(640)은 싱크 블록으로부터 비동기적 이전으로부터의 각각의 가능한 복귀로의 엣지를 표현하는 명령어를 포함한다. 예를 들어, 도 5에서, 명령어 (520)에서 시작하는 비동기적 이전은 라벨(L1)에서 복귀한다. 명령어(522, 530, 532)에서 시작하는 비동기적 이전은 라벨(L2)로 복귀하고, 이로부터 흐름은 라벨(L3)을 통과하여 정상적인 프로세싱을 복원한다. 따라서, 싱크 블록(640)은 라벨(L3)로 복귀하는 엣지를 표현하는 명령어(644)를 포함한다.

싱크 블록(640)은 또한 핸들러와 연관되어 있는 try 보디 밖에서 사용되지 않는 그 핸들러에서의 변수의 사용을 신호하는 의사 명령어를 포함한다. 의사 명령어(646)는 변수 Y가 핸들러 내부에서 사용됨을 신호한다. 이 예에서, 변수 Y는 라벨(L3)로 복귀하는 핸들러와 관련하여 사용된다. 따라서, 명령어(646)는 라벨(L3)을 가리키는 명령어(644)에 선행한다. 이와 같이, 핸들러 내에서의 변수의 사용은 핸들러의 실행 동안에 핸들러를 통과하는 경로에 대응하는 흐름도에서의 경로를 따라 표시된다.

도 6b는 도 6a에 예시된 함수에 대한 흐름도의 그래픽 표현이다. 이 함수는 여기서 핸들러가 없는 것으로 나타내어져 있다. 기술된 실시예에서, 프로그램의 피보호 영역은 보호자 영역(protector region)과 분리되어 모델링된다. 보호자 영역은 유사한 흐름도로 모델링될 수 있다.

흐름도(660)는 try 보디 영역의 블록들을 나타내는 다수의 블록(662, 664, 668, 670, 672)을 포함한다. 블록(674)은 싱크 블록(640)(도 6a)을 나타낸다. 블록(676)은 finally 핸들러의 일부로서 실행되는 명령어를 포함한다. 블록(678)은 try 보디 영역 밖의 명령어를 나타낸다.

블록은 엣지에 의해 연결된다. 엣지(682, 684, 686, 688)는 try 보디 내의 블록들을 연결시킨다. 엣지(690)는 try 보디로부터 try 보디 다음의 코드까지의 흐름을 나타낸다. 엣지(692, 694)는 핸들러로부터의 복귀 시의 흐름을 나타낸다. 엣지(681, 683, 685)는 핸들러로의 비동기적 흐름을 나타낸다.

명령어는 도시된 바와 같이 각각의 블록이 단일의 진입점(entry point)과 단일의 종료점(exit point)을 갖도록 블록들로 분할된다. 따라서, 코드는 각각의 블록이 분기 명령어에서 종료하도록 블록들로 분할된다. 이와 마찬가지로, 2개 이상의 장소로부터 진입할 수 있는 새로운 블록은 임의의 레벨에서 시작된다.

이제 도 7을 참조하면, 프로그램의 프로세싱의 플로우차트(700)가 예시되어 있다. 프로세스는 프로세스 블록(710)에서 시작한다. 프로세스 블록(710)에서, 프로그램의 중간 표현이 형성되고, 핸들러는 별도로 취급된다. 이 표현은 try 영역과 개별적인 핸들러 간의 흐름 경로를 모델링하지 않는다. 중간 표현을 사용하는지에 따라, 핸들러는 완전히 생략될 수도 있다. 핸들러로의/로부터의 흐름 및 핸들러 내에서의 변수의 사용을 표현하는 것이 적절할 수 있다. 다른 대안에서, 핸들러는 서로소 함수로서 표현되거나 임의의 다른 적당한 방식으로 표현될 수 있다. 블록(710)에서 생성된 중간 표현은 핸들러로의/로부터의 모든 가능한 엣지의 표현을 포함할 필요가 없다.

블록(710)에서 형성된 중간 표현은 임의의 적당한 형태일 수 있다. 예를 들어, 이는 도 3 및 도 4와 관련하여 나타낸 것과 같은 그래픽 표현을 포함할 수 있다. 다른 대안에서, 중간 표현은 도 5 및 도 6a와 관련하여 나타낸 바와 같은 명령어 및 텍스트 기반 명령어 및 의사 명령어를 사용할 수 있다.

중간 표현은 프로세싱될 프로그램의 전부 또는 일부분을 포함할 수 있다. 본 명세서에 제공된 예들에서, 단일의 try 영역을 갖는 간단한 프로그램이 예시를 위해 사용된다. 프로세싱될 프로그램은 다수의 try 영역을 포함할 수 있으며, 이들 모두는 예시된 try 영역과 동일한 방식으로 프로세싱될 수 있다.

프로세스 블록(712)에서, 싱크 블록이 부가된다. 예시된 실시예에서, 하나의 싱크 블록이 각각의 try 영역에 대해 부가된다. 그렇지만, 싱크 블록과 try 영역 간에 일대일 대응관계가 있을 필요는 없다. 예를 들어, 어떤 try 영역은 싱크 블록을 갖지 않는 것으로 표현될 수 있다. 다른 try 영역은 2개 이상의 싱크 블록을 갖는 것으로 표현될 수 있다.

프로세스 블록(714)에서, 엣지는 try 보디 영역 밖에서 활성인 변수의 각각의 정의 이후에 부가된다. 각각의 엣지는 명령어 이후에 시작하여 관련 핸들러에 대한 싱크 블록에서 끝난다. 예시된 실시예에서, try 영역 "밖에서 활성"(live-out)인 변수는 try 보디로부터의 비동기적 이전 이후에만 실행되는 try 영역의 일부분에서 사용되는 변수를 밖에서 활성인 것으로서 분류하는 수정된 활성 상태 알고리즘을 사용하여 식별된다. 이러한 알고리즘의 예가 이하에서 도 8a 및 도 8b와 관련하여 설명된다.

프로세스 블록(716)에서, 비동기적 이전 이후에 실행이 복귀할 수 있는 지점들 모두를 식별하기 위해 핸들러가 프로세싱된다. 싱크 블록으로부터 이들 장소 각각으로의 엣지가 부가된다.

프로세스 블록(718)에서, 각각의 try 보디를 래핑하는 엣지가 중간 표현에 부가된다. try 보디를 래핑하는 엣지의 예는 명령어(620)(도 6a)이다.

프로세스 블록(720)에서, 중간 표현은 try 보디 밖에서 사용되지 않지만 핸들러에서 사용되는 변수를 표현하기 위해 확장된다. 중간 표현에 대한 확장은 도 6a에 나타낸 명령어와 같이 OPSIDEEFFECT 코드를 사용하는 의사 명령어 등의 임의의 적당한 형태일 수 있다. 다른 대안에서 또는 그에 부가하여 중간 표현과 연관된 심볼 테이블에서 주석 첨부가 행해질 수 있거나 정보가 임의의 적당한 형태로 표현될 수 있다.

프로세스 블록(722)에서, 프로그램은 그 결과 얻어지는 중간 표현을 사용하여 프로세싱된다. 일 실시예에서, 중간 표현은 컴파일러에서 사용된다. 컴파일러는 전역적 최적화 및 코드 생성을 위해 중간 표현을 사용한다. 이는 데드 코드 제거, 스케쥴링, 코드 이동, 가비지 컬렉션 및 공통 부분식 제거(common sub-expression elimination) 등의 프로세스를 위해 사용될 수 있다. 컴파일러는 프로세서 기반 시스템에 로드되어 실행될 수 있는 기계어 코드를 생성할 수 있다. 그렇지만, 중간 표현은 실행가능 파일을 생성하는 데 사용될 필요가 없다. 중간 표현은 프로그램이 실행될 때 기계어 명령어가 생성되는 인터프리트형 언어(interpreted language)와 관련하여 사용될 수 있다. 그렇지만, 중간 표현이 기계어 코드를 생성하는 데 사용될 필요가 전혀 없다. 중간 표현은 예를 들어 프로그램의 해석을 돕는데, 동작을 시뮬레이션하는 데 또는 임의의 다른 원하는 목적을 위해 사용될 수 있다.

도 7에 도시된 프로세싱은 임의의 적당한 방식으로 수행될 수 있다. 일 실 시예에서, 중간 표현은 종래의 컴퓨터 상에서 실행되는 소프트웨어 도구를 사용하여 생성된다. 소프트웨어 도구는 현재 알려져 있거나 이후에 개발된 것이든지간에, 임의의 적당한 프로그래밍 언어로 구현될 수 있다.

도 7은 수정된 활성 상태(live-ness) 정의에 기초하여 중간 표현에 엣지가 부가되는 프로세스 블록(714)을 포함한다. 수정된 정의에 따르면, 변수가 try 보디 영역 밖으로의 비동기적 이전 이후에 사용되는 경우, 그 변수는 활성인 것으로 간주된다. 변수가 비동기적 이전 이후에 실행되는 프로그램의 다른 영역에서 활성인 경우 그 변수는 밖에서 활성(live-out)인 것으로 간주된다. 또한, 변수가 비동기적 이전 이후에 액세스되는 try 보디의 영역에서 활성인 경우 그 변수는 밖에서 활성인 것으로 간주될 수 있다. 그 변수가 그 영역에서만 사용되는 경우, 그 변수는 try 보디 밖에서 활성인 변수들의 세트에 벌써 포함되어 있지는 않을 것이며 따라서 그 세트에 부가될 필요가 있다.

도 8a는 수정된 정의에 따라 try 보디의 밖에서 활성인 변수를 식별하는 프로세스의 플로우차트이다. 예시된 실시예에서, 프로세싱은 컴파일되고 있는 함수에 대해 수행된다. 그렇지만, 프로세스는 보다 일반적으로 임의의 목적을 위해 프로세싱되는 임의의 프로그램 또는 코드 유닛에 적용될 수 있다.

프로세스는 프로세스 블록(810)에서 시작한다. 도 8a에 도시된 프로세스는 중간 표현이 부분적으로 준비된 후에 시작한다. 기술된 실시예에서, 도 8a의 프로세스는 초기의 중간 표현이 비동기적 이전의 효과를 반영하기 위해 확장되기 전에 수행된다.

이 형태에서, 함수는 그를 흐름도와 연관시키고, 블록들은 중간 표현으로부터 식별될 수 있다. 중간 표현은 또한 함수 내의 영역들 간의 상호 연결을 보여주는 영역 그래프(region graph)를 포함할 수 있다. 이 예에서, 각각의 영역은 그와 연관된 3가지 타입, 즉 try, 핸들러(handler) 또는 루트(root) 중 하나를 갖는다. 루트는 영역 트리의 최상단에 있는 비보호 영역(unprotected region)이다. 영역 그래프가 트리로서 간주될 수 있도록 영역들이 네스트(nest)될 수 있으며, 브랜치(branch)는 영역들이 네스트되는 방식에 의해 정의된다.

도 8a의 프로세스는 임의의 적당한 방식으로 구현될 수 있다. 기술된 실시예에서, 프로세스는 중간 표현을 형성하는 도구에 의해 사용되는 소프트웨어 드라이버에 의해 수행된다. 테이블 I는 도 8a의 프로세스를 구현하는 데 사용될 수 있는 의사 코드의 예를 제공한다. 임의의 적당한 프로그래밍 언어가 의사 코드로부터 프로그램을 생성하는 데 사용될 수 있다. 예를 들어, C++ 또는 C# 프로그래밍 언어가 사용될 수 있다. 첨부된 컴퓨터 프로그램 리스트(이는 본 출원의 개시 내용의 일부를 형성함)는 테이블 I, II, 및 III에 나타낸 의사 코드가 어떻게 구현될 수 있는지의 예를 제공한다.

프로세스 블록(810)에서, 프로그램 내의 각 블록에 대해 안에서 활성(live-in)인 변수가 계산된다. 예시된 실시예에서, 변수의 활성 상태는 흐름도와 서로소인 핸들러 영역으로 판정되며, 따라서 핸들러 영역에서의 변수의 사용은 활성 상태 계산에 영향을 미치지 않는다. 그렇지만, 전통적인 활성 상태 계산이 사용될 수 있다.

프로세스 블록(812)에서, 비동기적 진입점만을 갖는 블록이 식별된다. 비동기적 진입점은 핸들러 영역 내의 제어 이전 명령으로부터가 아니고서는 도달될 수없는 코드 내의 라벨에 의해 식별된다.

프로세스의 후속 단계들에서, 어느 변수가 모든 try 영역 내의 각각의 블록에 대해 안에서 활성(live-in)인지를 나타내는 변수가 영역별로 수집되어 각각의 try 보디 영역 밖에서 활성(live out)인 모든 변수의 세트를 생성한다.

블록들은 블록이 선택되는 프로세스 블록(814)에서 시작하여 한번에 하나씩 프로세싱된다. 테이블 I 내의 의사 코드는 컴파일되고 있는 함수와 연관된 흐름도가 그 영역 내의 모든 블록을 열거하는 list_of_basic_blocks라고 하는 데이터 구조에 대해 동작하는지를 나타낸다. 따라서, 프로세스 블록(814)에서, 프로세싱될 블록은 이 리스트 상의 그 다음 블록으로서 또는 임의의 다른 적당한 방식으로 선택될 수 있다.

결정 프로세스 블록(816)에서, 선택된 블록이 try 보디 영역 내부에 있는지에 대한 검사가 행해진다. 이 예에서, 각각의 try 보디 밖에서 활성인 변수들의 세트가 생성되고 따라서 try 보디 영역에 부가될 필요가 있는 엣지들이 식별될 수 있다. 따라서, try 영역 내에 있지 않은 블록들은 프로세싱될 필요가 없다.

선택된 블록이 try 영역에 있지 않은 경우, 실행은 결정 프로세스 블록(824)으로 진행한다. 결정 블록(824)에서 판정된 바와 같이, 프로세싱할 블록이 더 있는 경우, 실행은 프로세스 블록(814)으로 진행하여 추가의 블록이 선택된다. 이와 반대로, 프로세싱될 블록이 더 이상 없는 경우, 실행은 프로세스 블록(830)으로 진 행하여 이하에 기술된 바와 같이 프로세싱을 행한다. 테이블 I의 의사 코드에서, 이들 단계는 함수 내의 각각의 블록이 프로세싱됨을 표시하는 "foreach" 명령어로 표현되어 있다.

선택된 블록이 프로세싱되고 있는 try 보디 영역 내에 있는 경우, 프로세스는 결정 블록(816)에서 결정 블록(818)로 계속된다. 결정 블록(818)에서, 선택된 블록 뒤에 오는 블록도 역시 프로세싱되고 있는 try 보디 영역에 있는지 여부의 검사가 행해진다. 테이블 I의 의사 코드 내의 "foreach" 명령어에 의해 표시된 바와 같이, 2개 이상의 후손 블록(successor block)이 있는 경우, 각각이 고려된다.

후손 블록이 서로 다른 영역에 있는 경우 프로세싱은 프로세스 블록(822)으로 계속된다. 프로세스 블록(822)에서 후손 블록에 대해 안에서 활성인 변수는 try 보디 영역의 밖에서 활성인 변수들의 세트에 부과된다. try 보디 영역 밖에서 활성인 변수들의 세트에 대한 프로세싱은 임의의 적당한 방식으로 표현될 수 있다. 변수들의 세트를 표현하는 데 사용될 수 있는 데이터 구조의 예로는 비트 벡터(bit vector), 리스트(list) 및 데이터 테이블(data table)이 있다. 테이블 I에 예로서 주어진 프로그램에서, "live_out_of_region"은 각각의 영역과 관련하여 형성될 수 있는 데이터 구조를 말하고, "live_in"은 각각의 블록과 연관된 데이터 구조를 말한다. 이들 2개의 데이터 구조의 합집합이 계산된다. 이 동작은 후손 블록이 영역 밖에 있을 때, 그 블록에 대해 안에서 활성인 변수들이 그에 선행한 영역 밖에서 활성임을 나타낸다.

도 8a는 프로세스가 결정 블록(824)에서 계속됨을 보여준다. 더 많은 블록들이 남아 있는 경우, 프로세스는 프로세스 블록(814)으로 복귀하여, 추가의 블록들이 프로세싱된다. 각각의 블록이 프로세싱될 때, 그 블록이 영역 밖에 있는 후 손 블록을 갖는 경우, 그 후손에 대해 안에서 활성인 변수들이 프로세싱되고 있는 블록의 영역 밖에서 활성인 변수들을 나타내는 세트에 부가된다. 여기서, 변수들은 논리 UNION 동작을 사용하여 "부가"된다. 변수가 영역 밖에서 활성인 것으로 이미 열거되어 있는 경우, 그 변수를 리스트에 "부가"하는 것은 그 리스트에 영향을 주지 않는다.

함수 또는 다른 프로그램 내의 모든 블록이 프로세싱된 경우, 프로세스는 결정 블록(824)에서 프로세스 블록(830)으로 진행한다. 이 프로세스 블록에서, 핸들러로부터만 도달가능한 섹션을 갖는 영역에 대해 조정이 행해진다. 프로세스 블록(830)에 의해 수행되는 프로세싱은 이하의 테이블 I의 예에서의 메소드 AsyncLiveOutOfRegion에 의해 수행되며, 이는 이하에서 도 8b와 관련하여 보다 상세히 설명된다.

테이블 I

메소드 AsyncLiveOutOfRegion에 의해 수행되는 프로세스가 도 8b에 나타내어 져 있다. 테이블 II는 메소드 AsyncLiveOutOfRegion을 구현하는 데 사용될 수 있는 의사 코드의 예를 제공한다.

도 8b의 프로세스는 프로세스 블록(850)에서 시작한다. 도 8b의 프로세싱은 중간 표현을 작성하는 적어도 하나의 단계가 완료된 후에 수행된다. 이 상태에서, 프로세싱되고 있는 프로그램의 영역들은 영역들 간에 관계를 갖는 것으로 식별된다. 영역들은 다른 영역에 내포되어 트리 구조로서 간주될 수 있는 것을 생성할 수 있으며, 영역들은 트리의 노드를 형성하고 영역들 간의 관계는 노드 간의 연결을 정의한다.

도 8b에 의해 나타낸 프로세스는 영역들이 프로세싱되는 순서를 결정하기 위해 영역 트리 구조를 사용하여 프로세싱을 위한 영역들을 순서화한다. 기술된 실시예에서, 영역 트리는 후위 순회(post-order traversal)를 사용하여 프로세싱되며, 따라서 내포된 영역이 먼저 프로세싱된다.

테이블 II의 의사 코드 예에서, 후위 순회는 동일한 메소드를 재귀적으로 호출하는 "foreach" 루프로 달성된다. 메소드가 호출될 때마다, 프로세싱되는 영역은 그 자식 영역, 즉 내포된 영역 모두에 대해 메소드를 호출한다. 이러한 반복은 프로세싱될 모든 영역이 스택에 포함될 때까지 메소드에 대한 호출의 스택을 구축한다. 이어서, 각각의 호출은 스택에 배치된 역순으로 스택으로부터 프로세싱되어, 후위 순회를 생성한다. 테이블 II의 예에서, 프로세싱되고 있는 영역이 try 영역인 경우에만 호출이 행해진다.

도 8b에서, 프로세싱은 프로세스 블록(852)으로 진행한다. 프로세스 블록(852)에서, 프로세싱될 그 다음 영역이 선택된다. 영역이 결정 블록(854)에서 비동기적 진입을 갖지 않는 경우, 프로세싱은 결정 블록(870)으로 진행한다. 비동기적 진입을 갖지 않는 영역에 대해서는 어떤 추가의 프로세싱도 필요하지 않다. 어느 영역이 비동기적 이전에 의해서만 도달되는 섹션을 포함하는지를 나타내는 정보가 프로세스 블록(812)(도 8a)에서 수집될 수 있다.

이와 반대로, 영역이 결정 블록(854)에서 비동기적 진입점을 갖는 경우, 프로세싱은 프로세스 블록(856)으로 진행한다. 테이블 II의 예에서, 메소드 AsyncLiveOutOfATryRegion에 대한 호출에 의해 추가의 프로세싱이 수행되며, 이에 대해서는 테이블 III에 보다 상세히 나타내어져 있다. 진입점(856). AsyncLiveOutOfATryRegion에 대한 호출에 의한 추가의 프로세싱은 테이블 III에 보다 상세히 나타내어져 있다.

테이블 II

영역이 적어도 하나의 비동기적 진입점을 포함할 때, 프로세싱은 비동기적 진입으로 시작하는 영역 내의 블록이 선택되는 프로세스 블록(856)에서 계속된다. 프로세스 블록(856)은 비동기적 진입을 포함하는 블록들 각각이 프로세싱되도록 하는 결정 블록(864)으로 끝나는 루프의 시작이다. 테이블 III의 의사 코드 예에서, 이 루프는 "foreach" 명령어로 구현된다.

비동기적 진입점을 포함하는 블록에 대해, 프로세스 블록(858, 860, 862)에서의 프로세싱이 수행된다. 이들 프로세스 블록은 테이블 III에 나타내어진 메소드 AsyncUpdateLiveOutOfTry, AsyncUpdateContainingTryLiveness 및 AsyncUpdateContainedTryLiveness에 대응한다.

프로세스 블록(858)에서, 블록 안에서 활성인 것으로 식별되는 변수가 프로세싱되고 있는 블록을 포함하는 영역 밖에서 활성인 변수들의 세트에 부가된다.

프로세스 블록(860)에서, 단계(858)에서 영역 밖에서 활성인 것으로 식별된 변수들은 그 영역이 네스트되어 있는 영역(즉, 영역의 "부모")에 대해 밖에서 활성인 것으로 식별된 변수들의 세트에 부가된다.

프로세스 블록(862)에서, 선택된 블록 밖에서 활성인 것으로 식별된 변수들은 그 블록을 포함하는 영역에 내포된 임의의 영역에 대해 밖에서 활성인 것인 밖에서 활성인 변수들의 세트에 부가된다. 프로세스 블록(862)의 기능은 테이블 III에 예시된 AsyncUpdateContainedTryLiveness 등의 메소드에 의해 구현될 수 있다. 도시된 바와 같이, 그 메소드는 재귀적으로 메소드를 호출하는 "foreach" 루프를 포함하며, 이는 프로세싱이 각각의 자식 영역에 대해 수행됨을 나타낸다.

프로세스 블록(862) 이후에, 결정 블록(864)이 실행된다. 영역 내에 비동기 적 진입을 갖는 블록이 더 있는 경우, 프로세싱은 프로세스 블록(856)으로 복귀하여, 비동기적 진입을 갖는 그 다음 블록이 선택되어 프로세싱된다.

비동기적 진입을 갖는 블록이 더 이상 남아 있지 않은 경우, 프로세싱은 결정 블록(870)에서 시작된다. 프로세싱을 위한 try 영역이 더 남아 있는 경우, 프로세스는 프로세스 블록(852)으로 루프백하여, 그 다음 영역이 선택되어 프로세싱된다.

테이블 III

이와 같이 본 발명의 적어도 하나의 실시예의 몇가지 측면을 기술하였으므로, 여러가지 변경, 수정 및 개선이 당업자에게는 용이하게 안출될 수 있음을 잘 알 것이다.

예를 들어, 본 발명은 컴파일러와 관련하여 사용되는 것으로 예시되고 있다. 본 발명은 실행을 위해 컴퓨터 또는 다른 기계에 로드되는 실행가능 기계 코드를 생성하는 전통적인 컴파일러에서 유용할 수 있다. 그렇지만, 본 발명은 프로그램을 프로세싱하는 임의의 소프트웨어 도구와 관련하여 사용될 수 있다. 예를 들어, 본 발명은 프로그램을 실행하는 프로세서 상에 존재하고 또 필요에 따라 프로그램의 일부를 기계 코드로 변환하는 JIT(Just In Time) 컴파일러와 관련하여 사용될 수 있다.

이러한 변경, 수정 및 개선은 본 개시 내용의 일부이고 또 본 발명의 정신 및 범위 내에 속한다. 따라서, 이상의 설명 및 도면은 단지 예에 불과하다.

본 발명의 상기 실시예는 임의의 여러가지 방식으로 구현될 수 있다. 예를 들어, 실시예들은 하드웨어, 소프트웨어 또는 이들의 조합을 사용하여 구현될 수 있다. 소프트웨어로 구현될 때, 소프트웨어 코드는 단일의 컴퓨터에 제공되거나 다수의 컴퓨터 간에 분산되어 있거나간에, 임의의 적당한 프로세서 또는 프로세서들의 집합 상에서 실행될 수 있다. 상기한 기능들을 수행하는 임의의 컴포넌트 또는 컴포넌트들의 집합이 일반적으로 상기한 기능을 제어하는 하나 이상의 제어기로서 간주될 수 있음을 잘 알 것이다. 하나 이상의 제어기는 상기한 기능을 수행하기 위해 마이크로코드 또는 소프트웨어를 사용하여 프로그램되는 전용 하드웨어, 또는 범용 하드웨어(예를 들어, 하나 이상의 프로세서)와 같이 여러가지 방식으로 구현될 수 있다.

또한, 여기에 기술된 여러가지 방법 또는 프로세스는 여러가지 오퍼레이팅 시스템 또는 플랫폼 중 임의의 것을 이용하는 하나 이상의 프로세서 상에서 실행가능한 소프트웨어로서 코딩될 수 있다. 게다가, 이러한 소프트웨어는 다수의 적당한 프로그래밍 언어 및/또는 종래의 프로그래밍 또는 스크립팅 도구 중 임의의 것을 사용하여 작성될 수 있으며, 또한 실행가능 기계어 코드로서 컴파일될 수 있다.

이 점에서, 본 발명의 일 실시예는 하나 이상의 컴퓨터 또는 다른 프로세서 상에서 실행될 때 상기한 본 발명의 여러가지 실시예를 구현하는 방법을 수행하는 하나 이상의 프로그램으로 인코딩된 컴퓨터 판독가능 매체(또는 다중 컴퓨터 판독가능 매체)(예를 들어, 컴퓨터 메모리, 하나 이상의 플로피 디스크, 컴팩트 디스크, 광학 디스크, 자기 테이프, 기타 등등)에 관한 것이다. 컴퓨터 판독가능 매체 또는 매체들은 전송가능하게 될 수 있으며, 따라서 그 위에 저장된 프로그램 또는 프로그램들은 상기한 본 발명의 여러가지 측면을 구현하기 위해 하나 이상의 다른 컴퓨터 또는 다른 프로세서로 로드될 수 있다.

용어 "프로그램"은 본 명세서에서 일반적인 의미에서 상기한 본 발명의 여러가지 측면을 구현하기 위해 컴퓨터 또는 다른 프로세서를 프로그램하는 데 이용될 수 있는 임의의 타입의 컴퓨터 코드 또는 명령어 세트를 언급하는 데 사용된다. 게다가, 본 실시예의 한 측면에 따르면, 실행될 때 본 발명의 방법을 수행하는 하나 이상의 컴퓨터 프로그램이 단일 컴퓨터 또는 프로세서 상에 존재할 필요가 없고 본 발명의 여러가지 측면을 구현하기 위해 다수의 서로 다른 컴퓨터 또는 프로세서 간에 모듈 방식으로 분산될 수 있다.

본 발명의 여러가지 측면들은 단독으로, 조합하여, 또는 상기에서 기술한 실 시예들에서 구체적으로 기재되지 않은 다양한 구성으로 사용될 수 있으며, 따라서 그의 응용에 있어서 상기 설명에 기술되거나 도면에 예시된 컴포넌트의 상세 및 구성에 한정되지 않는다. 예를 들어, 일 실시예에 기술된 측면들은 다른 실시예에 기술된 측면과 임의의 방식으로 결합될 수 있다.

청구항 구성요소를 수식하기 위해 청구항에서의 "제1", "제2", "제3", 기타 등등과 같은 통상의 용어의 사용은 그 자체로서 한 청구항 구성요소의 다른 것에 대한 어떤 우선순위, 우선권, 또는 순서, 또는 방법의 단계들이 수행되는 시간적 순서를 암시하는 것이 아니라 단지 청구항 구성요소들을 구분하기 위해 어떤 이름을 갖는 한 청구항 구성요소를 동일한 이름을 갖는(그렇지만 서수항의 사용을 위한) 다른 구성요소와 구별하기 위한 라벨로서 사용된다.

게다가, "부가하는" 및 "수집하는" 등의 용어는 객체의 세트의 생성을 기술하기 위해 사용된다. 이러한 세트를 생성함에 있어서, 세트의 요소가 생성되거나 세트에 부가되는 순서가 본 발명에 중요하지는 않다. 세트의 요소는 임의의 순서로 또는 심지어 동시에 생성될 수 있다. 세트의 요소는 생성된 순서로 또는 임의의 다른 순서로 세트의 요소로서 식별될 수 있다.

또한, 본 명세서에서 사용된 어구 및 용어는 설명을 위한 것이며 한정적인 것으로 간주되어서는 안된다. 본 명세서에서 "포함하는", "구비하는", 또는 "갖는", "내포하는", "수반하는" 및 그의 변형의 사용은 그 후에 열거된 항목 및 그의 등가물은 물론 부가의 항목을 포괄하기 위한 것이다.

컴퓨터 프로그램 리스트

유의할 점은 이 알고리즘이 모든 예외 핸들러를 완전히 무시하는 흐름도 상에서 수행된다는 것이다. JIT64에서, 우리는 이들을 부모 메소드에서 빼내어 끝에 있는 EXIT문에 서로소 함수로서 첨부하였다. SESE 영역을 형성하는 것 등의 다른 메소드는 핸들러를 무시할 수 있다.

블록 레벨에서(부모 메소드에서만) 안에서 활성 및 밖에서 활성을 계산한 후에, 우리는 이것을 EH 영역 그래프로 매핑해야 한다. 구체적으로 말하면, 우리는 각각의 try 영역에 대해 영역 밖에서 활성을 계산한다. 이어서, 우리는 비동기적으로만 도달되는 블록을 사용하여 영역 밖에서 활성의 정의를 확장한다. 이 확장은 MSIL_AsyncLiveOutOfRegion()에서 행해지며, 여기서 호출 사이트(call site)가 굵은체이다. 이 피호출자의 상세는 다음 페이지 상에 기술되어 있다. 이하는 최상위 레벨 드라이버이다.

최상위 레벨 드라이버는 영역 트리의 후위 순회를 수행한다. 이 드라이버가 트리 내의 노드에 대한 반복으로부터 "팝 백(pop back)"할 때, 실행은 루프 밖으로 나간다. 이 드라이버는 이어서 try 영역인(즉, EH 영역 그래프에서 핸들러 노드가 아닌) 임의의 영역을 프로세싱한다.

이 드라이버는 이하에서 상세히 기술되는 "작업자(worker)" 루틴 MSIL_AsyncLiveOutOfATryRegion을 사용한다.

직관적으로, EH 영역 트리의 간단한 재귀적, 후위 순회는 강제로 "인사이드-아웃(inside-out)" 순서로 한다. 따라서, 가장 깊게 네스트된 try 영역들은 이들 을 포함하는 임의의 try 영역 이전에 프로세싱된다.

// 이어서 안에서 활성인 것을 try 보디의 (비동기적으로 도달가능한)

//이 하위 영역에, 전체 try 밖에서 활성인 것에 부가한다.

//세트 {live_out_of_region}는 영역 노드 상에 유지된다.

//이 캐싱된 노드 데이터는 전체 try 보디를 프로세싱한 후에

//점진적 업데이트를 위해 사용된다.

// #1

// 이 try에 대한 live_out_of_region을 업데이트함

//#2

//이제 새로운 정보를 임의의 다른 _containING_outer try 보디로

//밖으로 전파함

//#3

//이제 새로운 정보를 임의의 다른 _containED_deeper try 보디로

//밖으로 전파함

마지막으로, 우리는 영역 밖에서 활성에 대한 정의를 확장할 수 있게 해주는 키 블록을 찾는 알고리즘의 상세를 제공한다.

//핸들러로부터만 도달되는 try 보디 내의 이 라벨에 대해, 임의의 새로운

// live_out_of_region 기여를 찾는다. 이것은 비동기적 진입을 표시하는

// 라벨로부터의 경로 상에 있는 임의의 상향 노출된 USE이고 try 영역에

//구문적으로 포함된 모든 엣지를 통해 try의 최상단으로부터 도달되지

//않는다.

Claims (20)

1. 프로그램을 프로세싱하는 방법으로서, 상기 프로그램은 제1 영역과 제2 영역을 포함하여 구성되며, 상기 제1 영역은 프로그램의 실행이 상기 제1 영역으로부터 프로그램 내 핸들러 영역으로 비동기적으로 이전될 수 있고, 상기 핸들러 영역과 연관된 피보호 영역이며, 상기 제2 영역은 상기 제1 영역의 일 부분으로서 상기 핸들러 영역 내의 적어도 하나의 명령이 실행된 후에만 실행되고,

   상기 방법은,

   a) 적어도 상기 제1 영역의 표현을 형성하는 단계 - 상기 표현은 각각이 하나 이상의 동작을 나타내는 복수의 제1 타입 구문 및 각각이 상기 제1 타입의 구문들 간의 실행 흐름을 나타내는 적어도 하나의 제2 타입 구문을 포함함 - , 및

   b) 변수의 정의를 포함하는 상기 제1 영역 내의 적어도 하나의 제1 타입 구문에 대해, 상기 변수가 상기 제2 영역에서 사용되는지 여부에 기초하여 상기 제1 타입 구문으로부터의 흐름을 나타내는 제2 타입 구문을 상기 표현에 선택적으로 부가하는 단계를 포함하며,

   상기 단계 a) 및 b)는 컴퓨터 상에서 실행하는 컴파일러에 의해 수행되는, 프로그램을 프로세싱하는 방법.
2. 제1항에 있어서, 상기 변수가 상기 제2 영역에서 사용되는지 여부에 기초하여 제2 타입 구문을 상기 표현에 선택적으로 부가하는 단계는,

   a) 상기 변수가 상기 제1 영역 밖에서 활성(live)인지 여부를 결정하는 단계; 및

   b) 상기 변수가 상기 제1 영역 밖에서 활성인 경우 제2 타입 구문을 상기 표현에 부가하는 단계

   를 포함하는, 프로그램을 프로세싱하는 방법.
3. 제1항에 있어서, 상기 핸들러 영역은 상기 제2 영역과 별개이며, 상기 제1 영역으로부터 상기 핸들러 영역으로의 프로그램 실행의 이전은 비동기적인, 프로그램을 프로세싱하는 방법.
4. 제1항에 있어서, 상기 변수가 상기 제2 영역에서 사용되는지 여부에 기초하여 상기 제1 타입 구문으로부터의 흐름을 나타내는 제2 타입 구문을 상기 표현에 선택적으로 부가하는 단계는 상기 변수가 상기 제1 영역에서만 이용되는 경우 상기 제2 타입 구문을 부가하지 않는 단계를 포함하는, 프로그램을 프로세싱하는 방법.
5. 핸들러와 연관된 프로그램 내 피보호 영역인 제1 영역, 상기 제1 영역의 일 부분인 제2 영역 및 상기 핸들러에 대응하는 프로그램 내 제3 영역에 명령어를 갖는 타입의 프로그램을 프로세싱하기 위한 컴퓨터 판독가능 저장 매체로서, 프로그램 실행이 상기 제1 영역에서 상기 제3 영역으로 비동기적으로 이전될 수 있고 상기 제2 영역 내의 명령어는 상기 제3 영역 내의 명령어의 실행 이후에만 실행될 수 있는 컴퓨터 판독가능 저장 매체에 있어서,

   상기 컴퓨터 판독가능 저장 매체는,

   a) 상기 제1 영역 및 상기 제2 영역을 포함하는 표현을 형성하는 단계 - 상기 표현은 복수의 명령어 및 상기 복수의 명령어의 실행 순서를 나타내는 정보를 포함함 - , 및

   b) 변수의 정의를 포함하는 상기 제1 영역 내의 적어도 하나의 명령어에 대해, 상기 명령어가 상기 제2 영역에서 사용되는 변수를 정의하는 경우에 대한 표시를 상기 표현에 선택적으로 부가하는 단계

   를 포함하는 단계들을 수행하기 위한, 컴퓨터 실행가능 명령어를 갖는 컴퓨터 판독가능 저장 매체.
6. 제5항에 있어서, 상기 표현을 형성하는 단계는 흐름 그래프를 형성하는 단계를 포함하고, 표시를 상기 표현에 부가하는 단계는 흐름 그래프에 엣지를 부가하는 단계를 포함하는 컴퓨터 판독가능 저장 매체.
7. 핸들러와 연관된 프로그램 내 피보호 영역인 제1 영역, 상기 제1 영역의 일 부분인 제2 영역 및 상기 핸들러에 대응하는 프로그램 내 제3 영역을 갖는 프로그램을 프로세싱하며, 프로그램 실행이 상기 제3 영역에서 상기 제2 영역으로 비동기적으로 이전될 수 있고 상기 제2 영역은 상기 프로그램의 상기 제1 영역 밖으로의 상기 비동기적인 이전 이후에만 실행되는, 소프트웨어툴(software tool)을 포함하는 컴퓨터 판독가능 저장 매체에 있어서, 상기 소프트웨어툴은,

   a) 프로세서에 의해 실행될 때, 상기 제1 영역 및 상기 제2 영역을 포함하는 표현을 형성하는 모듈 - 상기 표현은 복수의 블록 및 복수의 엣지를 포함함 - ,

   b) 프로세서에 의해 실행될 때, 상기 표현에 엣지를 선택적으로 부가하는 모듈 - 상기 모듈은 변수의 정의를 포함하는 상기 제1 영역 내의 블록들을 프로세싱하고, 상기 변수가 상기 제2 영역 및 상기 제3 영역 중 적어도 하나에서 사용되는지 여부에 기초하여 블록으로부터의 엣지를 상기 표현에 선택적으로 부가함 -

   을 포함하는 컴퓨터 판독가능 저장 매체.
8. 제7항에 있어서, 상기 소프트웨어 툴은 영역 내의 블록에서 정의된 변수가 상기 영역 밖에서 활성인지 여부를 나타내는 활성 상태를 판정하는 모듈을 더 포함하고,

   엣지를 선택적으로 부가하는 상기 모듈은 상기 제1 영역 내의 블록에서 정의된 변수의 활성 상태를 판정하기 위해, 상기 활성 상태를 판정하는 모듈에 엑세스하고, 상기 변수가 상기 제1 영역 밖에서 활성인 경우 엣지를 추가하도록 구성된 컴퓨터 판독가능 저장 매체.
9. 적어도 하나의 핸들러와 연관된 프로그램 내 피보호 영역인 제1 영역을 포함하는 프로그램 내 복수의 영역들 - 상기 적어도 하나의 핸들러는 상기 제1 영역에서 발생하는 적어도 하나의 예외(exception)를 프로세싱하기 위한 적어도 하나의 명령어를 포함함 - 을 갖는 프로그램을 프로세싱하는 방법에 있어서, 상기 적어도 하나의 예외의 발생시 상기 제1 영역으로부터 상기 적어도 하나의 핸들러로의 프로그램 제어의 이전은 비동기적으로 되며, 상기 방법은,

   (a) 상기 제1 영역으로부터의 프로그램 제어의 이전이 동기적으로 되는 임의의 영역에서, 변수가 상기 제1 영역 밖에서 이용되는지 여부를 판정하는 단계,

   (b) 프로그램 제어의 이전이 비동기적으로 되는 임의의 영역에서 상기 변수가 상기 제1 영역 밖에서 이용되는지 여부를 판정하는 단계,

   (c) 상기 적어도 하나의 핸들러의 실행에 후속하여서만 액세스 가능한 상기 제1 영역의 일 부분에서 상기 변수가 이용되는지 여부를 판정하는 단계, 및

   (d) 상기 단계들 (a), (b) 또는 (c) 중 임의의 하나 이상에서 상기 변수가 상기 제1 영역 밖에서 이용되는 경우 상기 변수를 상기 제1 영역 밖에서 활성인 것으로 분류하는 단계

   를 포함하는, 프로그램을 프로세싱하는 방법.
10. 제9항에 있어서, 상기 제1 영역 내에서 정의된 변수들이 상기 제1 영역 밖에서 활성인 것으로 분류되는 지 여부를 나타내는 데이터 구조를 형성하는 단계를 포함하는, 프로그램을 프로세싱하는 방법.
11. 제9항에 있어서, 상기 제1 영역은 프로그램 내의 try 영역으로서 그 안에 다른 try 영역들을 내포할 수 있고, 상기 제1 영역 밖에서의 활성 상태를 판정하는 단계는 상기 try 영역 밖에서의 활성 상태를 판정하는 단계 및 상기 try 영역에 내포된 다른 try 영역들 밖에서의 활성 상태를 판정하는 단계를 포함하는, 프로그램을 프로세싱하는 방법.
12. 프로그램의 제1 영역 밖에서 변수들의 활성 상태를 판정하는 방법 - 상기 제1 영역은 적어도 하나의 핸들러와 연관된 프로그램 내 피보호 영역이고, 상기 적어도 하나의 핸들러는 상기 제1 영역과 별개인 적어도 하나의 부분을 갖는 상기 프로그램의 상기 적어도 하나의 예외에 응답하여 비동기적 이전이 발생시 상기 제1 영역에서 발생하는 적어도 하나의 예외를 프로세싱하기 위한 적어도 하나의 명령어를 포함함 - 에 있어서, 상기 방법은,

    a) 상기 프로그램의 중간 표현을 형성하는 단계 - 상기 중간 표현은 복수의 블록들을 포함하며, 상기 복수의 블록들은, 각각이 상기 제1 영역의 일 부분을 나타내는 상기 블록들의 일 부분과 각각이 상기 제1 영역과 별개인 상기 프로그램의 일 부분을 나타내는 상기 블록들의 일 부분을 갖는 적어도 후손 블록들을 정의하는 상호관계들을 가짐 -,

    b) 각각의 변수의 세트가 상기 복수의 블록들 중 하나와 연관되어 있는 복수의 안에서 활성인 변수들의 세트들을 식별하는 단계 - 상기 안에서 활성인(live-in) 변수들의 세트는 연관된 블록에 대하여 안에서 활성인 변수들을 정의함 - ,

    c) 비동기적 진입들(entrances)을 갖는 블록들을 식별하는 단계, 및

    d) 상기 복수의 안에서 활성인 변수들의 세트들 중 선택된 세트들의 결합을 형성하여 상기 제1 영역의 밖에서 활성 상태인 밖에서 활성인(live-out) 변수들의 세트를 누적하는 단계 - 상기 안에서 활성인 변수들의 선택된 세트들은 선택된 블록들과 연관된 세트들을 포함하며,

    i) 상기 선택된 블록들의 제1 부분에 대하여, 각각의 선택된 블록은 상기 제1 영역과 별개인 프로그램의 일 부분을 나타내고 상기 제1 영역의 일 부분을 나타내는 블록의 후손이 되고,

    ii) 상기 선택된 블록들의 제2 부분에 대하여, 각각의 선택된 블록들은 상기 제1 영역과 연관된 상기 적어도 하나의 핸들러를 나타내고 비동기적 진입을 가지며,

    iii) 상기 선택된 블록들의 제3 부분에 대하여, 각각의 선택된 블록은 상기 적어도 하나의 핸들러의 실행에 후속하여서만 액세스 가능한 적어도 하나의 진입을 갖는 상기 제1 영역의 일 부분을 나타냄 -

    를 포함하는, 프로그램을 프로세싱하는 방법.
13. 제12항에 있어서, 상기 복수의 블록들 및 이들의 상호관계들은 적어도 하나의 브랜치를 갖는 블록들의 트리를 정의하며, 밖에서 활성인(live-out) 변수들의 세트를 누적하는 단계는,

    a) 제1 방향으로 상기 브랜치를 트래버스(traverse)하고, 상기 제1 영역과 별개인 상기 프로그램의 일 부분을 나타내며 상기 제1 영역의 일 부분을 나타내는 블록의 후손인 블록들과 연관된 안에서 활성인 변수들의 세트들을 누적하는 단계, 및

    b) 상기 제1 영역과 연관된 상기 적어도 하나의 핸들러를 나타내고 비동기적 진입을 갖는 블록들 및 상기 적어도 하나의 핸들러의 실행에 후속하여서만 액세스 가능한 적어도 하나의 진입을 갖는 상기 제1 영역의 일 부분을 나타내는 블록들과 연관되는 안에서 활성인 변수들의 세트들을 누적하면서 제2 방향으로 상기 브랜치를 트래버스하는 단계

    를 포함하는, 프로그램을 프로세싱하는 방법.
14. 제12항에 있어서, 비동기적 진입들을 갖는 블록들을 식별하는 단계는 본질적으로 비동기적 진입들만 갖는 블록들을 식별하는 단계를 포함하는, 프로그램을 프로세싱하는 방법.
15. 프로세서 및 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 시스템으로서, 상기 컴퓨터 판독가능 저장 매체는 컴퓨터 실행가능 프로그램의 특성을 나타내도록 형성된 데이터 구조를 기록하고 있으며, 상기 데이터 구조는 프로그램 내 피보호 영역, 적어도 하나의 핸들러 - 상기 적어도 하나의 핸들러는 적어도 하나의 예외에 응답하여 비동기적 이전이 발생할 경우 상기 피보호 영역 내에서 발생하는 적어도 하나의 예외를 프로세싱하기 위한 적어도 하나의 명령어를 포함함 - 및 상기 피보호 영역 밖의 적어도 하나의 프로그램 내 영역을 가지며,

    상기 데이터 구조는 복수의 데이터 필드들 - 각각의 데이터 필드는 상기 컴퓨터 실행가능 프로그램의 상기 피보호 영역 내의 변수에 대응하고 상기 변수가 활성인지 여부를 나타내는 값을 저장함 - 을 포함하며,

    상기 프로세서는,

    (a) 상기 변수가 상기 피보호 영역 밖에서 사용되는지(consumed) 여부를 판정하는 단계,

    (b) 상기 변수가 상기 적어도 하나의 핸들러의 실행에 후속하여서만 엑세스 가능한 상기 피보호 영역의 일 부분 내에서 사용되는지 여부를 판정하는 단계, 및

    (c) 상기 변수가 상기 판정하는 단계 (a) 또는 (b)에서 사용되면 상기 변수를 활성인 것으로 분류하는 단계

    에 의하여 상기 변수가 활성인지 여부를 판정하도록 프로그래밍되는 컴퓨터 시스템.
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제

Images