KR20080071135A - 소프트웨어 트랜잭션 메모리 블록들을 포함하는 프로그램의컴파일을 위한 방법 - Google Patents

Abstract

효율적인 성능을 달성하기 위하여 소프트웨어 트랜잭션 메모리 명령들에 대한 최적화를 수행하는 소프트웨어 트랜잭션 메모리 시스템이 설명된다. 소프트웨어 트랜잭션 메모리 블록들은 소프트웨어 트랜잭션 메모리 명령들로 대체되며, 이어서 이들은 분해된 소프트웨어 트랜잭션 메모리 명령들로 더 분해된다. 분해된 명령들은 명령 시맨틱스에 대한 지식을 갖는 컴파일러가 통상의 소프트웨어 트랜잭션 메모리 시스템들에서 이용할 수 없는 최적화들을 수행하는 것을 허가한다. 프로시저 호출들 주위의 코드 이동, 강한 아토믹성을 제공하는 연산들의 추가, 불필요한 판독/갱신 업그레이드들의 제거, 및 새로 할당된 개체들에 대한 연산들의 제거와 같은 고 레벨 소프트웨어 트랜잭션 메모리 최적화들이 수행된다.

소프트웨어 트랜잭션 메모리 시스템, 컴파일러, 메모리 최적화, 아토믹

Description

소프트웨어 트랜잭션 메모리 블록들을 포함하는 프로그램의 컴파일을 위한 방법{OPTIMIZATION OF SOFTWARE TRANSACTIONAL MEMORY OPERATIONS}

<관련 출원들의 상호 참조>

본 출원은 2005년 12월 7일자로 출원된 미국 가출원 번호 60/748,386의 이익을 주장하는 2006년 3월 23일자로 출원된 미국 특허 출원 번호 11/389,451의 이익을 주장한다.

멀티 스레드 프로세스의 다수의 스레드는 동시 실행 동안 공통 메모리 위치들을 공유하는 것이 일반적이다. 결과적으로, 멀티 스레드 프로세스의 2개의 상이한 스레드는 프로그램에 의해 액세스될 수 있는 동일 메모리 위치를 판독하고 갱신할 수 있다. 그러나, 하나의 스레드가 공유 메모리 위치의 값에 의존하는 연산들의 시퀀스의 중간에 있는 동안, 다른 스레드가 그 값을 변경하지 않는 것을 보장하도록 주의해야 한다.

예를 들어, 프로그램이 상이한 은행 계좌 내의 총액을 각각 나타내는 2개의 상이한 소프트웨어 개체의 내용들에 액세스하고 있는 것으로 가정한다. 최초에, 제1 계좌의 총액은 메모리 어드레스 A1에 저장된 $10인 반면, 제2 계좌의 총액은 메모리 어드레스 A2에 저장된 $200이다. 뱅킹 프로그램의 제1 스레드가 A2에서 A1으로 $100을 전송하도록 코딩되고, 제2 스레드가 양 계좌 내의 자금의 총액을 계산 하도록 코딩된다. 제1 스레드는 A1의 내용에 $100을 더함으로써 시작하여 이를 $110으로 갱신한 후, 계속해서 A2의 내용으로부터 $100을 빼서 이를 $100으로 갱신한다. 그러나, 제2 스레드가 이들 두 연산 사이에 실행될 경우, 제2 스레드는 양 계좌에 대해 $210의 정확한 총액이 아니라 $310의 부정확한 총액을 계산할 수 있다.

소프트웨어 트랜잭션 메모리는 스레드가 일련의 공유 메모리 액세스들을 안전하게 수행하여 스레드가 다른 스레드로부터의 간섭 없이 그의 트랜잭션을 완료하는 것을 가능하게 할 수 있는 프로그래밍 추상화를 제공한다. 따라서, 트랜잭션 메모리들은, 제1 스레드의 전형적인 가산 및 감산을 포함하는 트랜잭션이 메모리 위치들(A1, A2)에 관하여 "아토믹"하며, 따라서 제2 스레드는 양 계좌 내의 정확한 총액을 계산할 것임을 보장하기 위하여 소프트웨어에서 사용될 수 있다.

그러나, 소프트웨어에서 트랜잭션 메모리를 구현하기 위한 기존의 접근법들은 성능 문제를 갖는다. 예를 들어, 하나의 기존 접근법에서는, 스레드가 트랜잭션 내의 메모리 위치들의 시퀀스에 액세스할 때, 스레드는 그가 트랜잭션 동안 판독하고 갱신(즉, 기입)하기를 원하는 메모리 위치들 및 값들의 개별 리스트를 유지하고, 이어서 트랜잭션의 종료시에 스레드는 실제 공유 메모리 위치들에서 이들 모든 값을 갱신한다. 트랜잭션 동안 스레드가 그의 리스트 내의 임의의 메모리 위치에 대해 재판독 또는 재기입하기를 원하는 경우, 스레드는 리스트 내의 메모리 위치의 엔트리를 검색하여 엔트리에 액세스해야 하는데, 이는 프로그램적으로 느린 방법이다. 따라서, 소프트웨어에서 트랜잭션 메모리를 구현하는 이러한 간접적인 방법은 열악한 성능을 갖는다.

또한, 소프트웨어에서 트랜잭션 메모리를 구현하기 위한 기존 접근법들은 트랜잭션 메모리 및 레코드 유지 명령들에 대한 불필요한 호출을 포함하는 상당한 오버헤드를 발생시켜, 특히 이들 명령이 비효율적인 방식으로 수행되는 경우에 프로그램들의 실행을 어렵게 한다. 또한, 몇몇 트랜잭션 메모리 스킴에 고유한 레코드 유지 활동들은 이들이 생성하는 레코드들의 생성 및 유지를 효과적으로 제한하지 못하며, 이는 메모리는 물론, 디스크 공간 및 다른 시스템 자원들을 낭비할 수 있다.

<발명의 요약>

소프트웨어 트랜잭션 메모리 시스템("STM")이 설명된다. 여기에 설명되는 시스템 및 기술들은 효율적인 성능을 달성하기 위해 소프트웨어 트랜잭션 메모리 명령들에 대한 최적화를 수행한다. 소프트웨어 트랜잭션 메모리 블록들을 소프트웨어 트랜잭션 메모리 명령들로 대체하고, 또한 이들 명령을 분해된 소프트웨어 트랜잭션 메모리 명령들로 분해하는 컴파일러가 설명된다. 컴파일러는 명령 시맨틱스의 지식을 이용하여, 통상의 소프트웨어 트랜잭션 메모리 시스템들 상에서 이용 가능하지 않은 최적화를 수행한다. 또한, 컴파일러는 STM 코드에 대한 고 레벨 최적화들을 수행한다. 이러한 최적화들 중 일부는 보다 낮은 레벨의 최적화들을 이용하기 위해 수행된다. 이러한 고 레벨 최적화들은 불필요한 판독/갱신 업그레이드들의 제거, 프로시저 호출들 주변의 STM 연산들의 이동, 및 새로 할당된 개체들에 대한 불필요한 연산들의 제거를 포함한다. 또한, STM 코드는 트랜잭션들 외부 에서 기입된 메모리 액세스들에 대한 강한 아토믹성(atomicity)을 제공하도록 최적화된다.

일례에서, 처리 장치 및 소프트웨어 트랜잭션 메모리 연산들의 지식을 갖도록 구성된 컴파일러를 포함하는 컴퓨터 시스템에서 소프트웨어 트랜잭션 메모리 블록들을 포함하는 프로그램을 컴파일하는 방법이 설명된다. 이 방법은 프로그램을 최적화하여 소프트웨어 트랜잭션 메모리 명령들을 포함하는 최적화된 프로그램을 생성하고, 최적화된 프로그램을 컴파일하는 단계를 포함한다.

본 요약은 아래의 상세한 설명에서 더 설명되는 개념들의 선택을 간략한 형태로 소개하기 위해 제공된다. 본 요약은 청구 발명의 중요한 특징들 또는 본질적 특징들을 식별하고자 하는 의도도 없고, 청구 발명의 범위를 결정하기 위한 보조물로서 이용하고자 하는 의도도 없다.

추가적인 특징들 및 이점들은 첨부 도면들을 참조하여 진행되는 아래의 실시예들의 상세한 설명으로부터 명확해질 것이다.

도 1은 아토믹 메모리 트랜잭션 블록들을 포함하는 소스 코드를 컴파일하는 데 사용되는 컴파일러의 블록도이다.

도 2는 도 1의 컴파일러의 컴포넌트들의 블록도이다.

도 3은 트랜잭션 메모리를 이용하여 프로그램을 컴파일하고 실행하는 예시적인 프로세스를 나타내는 흐름도이다.

도 4는 트랜잭션 메모리를 이용하여 프로그램을 컴파일하기 위해 도 1의 컴 파일러에 의해 수행되는 예시적인 프로세스를 나타내는 흐름도이다.

도 5는 고 레벨 소프트웨어 트랜잭션 메모리 최적화들을 수행하기 위해 도 1의 컴파일러에 의해 수행되는 예시적인 프로세스를 나타내는 흐름도이다.

도 6은 컴파일 동안 분해된 소프트웨어 트랜잭션 메모리 명령들을 최적화하기 위해 도 1의 컴파일러에 의해 수행되는 예시적인 프로세스를 나타내는 흐름도이다.

도 7은 강한 아토믹성을 구현하기 위한 연산들을 도입하기 위해 도 1의 컴파일러에 의해 수행되는 예시적인 프로세스를 나타내는 흐름도이다.

도 8은 판독/갱신 업그레이드들을 제거하기 위해 도 1의 컴파일러에 의해 수행되는 예시적인 프로세스를 나타내는 흐름도이다.

도 9는 판독/갱신 업그레이드들을 제거하기 위해 도 1의 컴파일러에 의해 수행되는 추가의 예시적인 프로세스를 나타내는 흐름도이다.

도 10은 프로시저 호출들 주변의 연산들을 이동시키기 위해 도 1의 컴파일러에 의해 수행되는 예시적인 프로세스를 나타내는 흐름도이다.

도 11은 새로 할당된 개체들에 대한 로그 연산들을 제거하기 위해 도 1의 컴파일러에 의해 수행되는 예시적인 프로세스를 나타내는 흐름도이다.

도 12는 새로 할당된 개체들에 대한 로그 연산들을 제거하기 위해 도 1의 컴파일러에 의해 수행되는 추가의 예시적인 프로세스를 나타내는 흐름도이다.

도 13은 소프트웨어 트랜잭션 메모리 시스템의 실행시간 환경에서 실행시간 동안 사용되는 소프트웨어 모듈들을 포함하는 블록도이다.

도 14a 및 14b는 다중 사용 헤더 워드들을 사용하는 전형적인 개체들을 나타내는 블록도들이다.

도 15a 및 15b는 변화 스냅샷을 갖는 전형적인 개체를 나타내는 블록도들이다.

도 16은 스냅샷들을 이용하여 개체를 검증하기 위한 도 6의 실행시간 환경의 예시적인 프로세스를 나타내는 흐름도이다.

도 17은 팽창된 헤더 워드를 이용하여 개체의 스냅샷을 수정하기 위한 도 6의 실행시간 환경의 예시적인 프로세스를 나타내는 흐름도이다.

도 18a 및 18b는 트랜잭션 실행의 사례들을 나타내는 블록도들이다.

도 19a-19c는 트랜잭션 실행의 추가 사례들을 나타내는 블록도들이다.

도 20은 로그 필터링을 위해 도 6의 실행시간 환경에서 사용되는 예시적인 연관 테이블을 나타내는 블록도이다.

도 21은 도 20의 연관 테이블을 이용하여 로그 엔트리들을 필터링하기 위한 도 6의 실행시간 환경의 예시적인 프로세스를 나타내는 흐름도이다.

도 22는 도 20의 연관 테이블을 이용하여 로그 엔트리들을 필터링하기 위한 도 6의 실행시간 환경의 추가의 예시적인 프로세스를 나타내는 흐름도이다.

도 23은 쓰레기 수집 동안 로그들을 압축하기 위해 도 6의 실행시간 환경에 의해 수행되는 예시적인 프로세스를 나타내는 흐름도이다.

도 24는 쓰레기 수집 동안 로그들을 압축하기 위해 도 6의 실행시간 환경에 의해 수행되는 추가의 예시적인 프로세스를 나타내는 흐름도이다.

도 25는 쓰레기 수집 동안 로그들을 압축하기 위해 도 6의 실행시간 환경에 의해 수행되는 추가의 예시적인 프로세스를 나타내는 흐름도이다.

도 26은 본 명세서에서 기술들을 구현하기 위한 적절한 컴퓨팅 환경의 블록도이다.

여기에서 설명되는 예들은 소프트웨어 및 하드웨어 기반 트랜잭션 메모리 시스템들은 물론, 이러한 시스템들에서의 성능 개선의 예들을 설명한다. 구체적으로, 아래의 구현 예들은 분해된 소프트웨어 트랜잭션 연산들, 코드 최적화들(이 용어는 아래에 설명됨)를 허가하기 위한 컴파일러 중간 표현("IR")에서의 STM 프리미티브들의 사용, 이러한 프리미티브들의 성능을 개선하도록 작용하는 컴파일러 개선들, 연관 테이블들을 사용하는 실행시간 로그 필터링, 및 효율적인 실행시간 개체 단위(per-object) 연산들을 설명한다. 여기에서 제공되는 설명들은 특정 소프트웨어 트랜잭션 메모리 구현의 최적화들로서 제공되지만, 여기에서 설명되는 기술들 및 시스템들은 다양한 구현에서 동작할 수 있으며, 여기에서 설명되는 기술들의 구현, 성능 또는 요건에 관한 어떠한 제한도 수반할 필요가 없음을 인식할 것이다.

1. 소프트웨어 트랜잭션 메모리 시스템의 예들

아토믹 블록들은 동시 프로그램들을 작성하는 문제에 대한 유망한 간소화를 제공한다. 여기에서 설명되는 시스템들에서, 코드 블록이 아토믹(atomic)으로 표기되며, 컴파일러 및 실행시간 시스템은 함수 호출들을 포함하는 블록 내의 연산들이 아토믹하게 보이도록 규정한다. 프로그래머는 더 이상 매뉴얼 로킹, 저 레벨 레이스 조건들 또는 데드록들에 대해 걱정할 필요가 없다. 아토믹 블록들은 또한 예외 회복을 제공할 수 있으며, 따라서 블록이 예외로 끝나는 경우에 블록의 부작용들이 제거된다. 이것은 에러 핸들링 코드를 작성하고 테스트하기가 종종 어려운 단일 스레드 애플리케이션에서도 가치있다. 아토믹 블록들의 구현들은 대형 멀티 프로세서 머신들로 스케일링되는데, 이는 아토믹 블록들이 병렬을 유지하여, 하나의 블록에서 갱신되고 있는 위치가 나머지 블록들 중 어떠한 블록에서도 액세스되고 있지 않는 한은 동시에 실행될 수 있기 때문이다. 이것은 통상의 데이터 캐시에서 허용되는 공유의 종류를 유지한다.

여기에서 설명되는 기술들은 컴파일러 및 실행시간 시스템에 단단히 통합된 STM 구현과 관련하여 이루어진다. 이 구현의 하나의 특징은 직접 갱신 STM이라는 점이다. 이것은 개체들이 개체들의 비공개 쉐도우 카피들 상에서가 아니라 힙에서 직접적으로, 또는 개체 참조와 현재의 개체 내용들 간의 임시 간접 호출 레벨들을 통해, 갱신되는 것을 허가한다. 이것은 성공적으로 커미트되는 트랜잭션들에 대해 보다 효율적이다.

여기에서 설명되는 시스템들 및 기술들은 분해된 STM 인터페이스를 제공하는 구현의 특징을 이용한다. 예를 들어, 트랜잭션 스토어 obj.field = 42는 (a) obj가 현재 스레드에 의해 갱신되고 있음을 기록하고, (b) field가 유지한 이전 값을 로깅하고, (c) 새로운 값 42를 필드에 저장하는 단계들로 분할된다. 이러한 새로운 설계는 트랜잭션 연산들에 대해 고전적 최적화들이 제공되는 것을 허가한다. 예를 들어, 상기 예의 세 단계는 컴파일러에 의해 개별적으로 처리되며, (a) 및 (b)는 종종 루프로부터 상승(hoist)될 수 있다. 여기에서 설명되는 기술들에서, 분해된 STM 인터페이스는 STM 인터페이스 및 시맨틱스에 대한 특정 지식을 갖는 컴파일러의 이용을 통해 보다 효율화되며, 이 인터페이스 상에서 특별히 작용하도록 구성되는 최적화들을 수행할 수 있다.

다른 예에서, 여기에서 설명되는 시스템들 및 기술들은 통합 트랜잭션 버전화를 이용하는 효율적인 개체 단위 연산들을 통해 기술되는 STM 구현의 효율을 설명한다. 이러한 구현들은 트랜잭션 버전화와 기존 개체 헤더 워드의 통합을 이용한다. 이것은 이들 시스템이 외부 버전화 레코드 테이블, 추가 헤더 워드, 또는 개체 참조와 현재 개체 내용 간의 간접 호출 레벨을 이용하므로 다른 STM 시스템들과 다르다. 이러한 접근법들은 열악한 캐시 지역성을 유발하거나 공간 사용량을 증가시킨다. 여기서 설명되는 구현은 트랜잭션 커미트 동안 팽창된 헤더 워드를 개체 수정의 빠른 검증을 허가하는 효율적인 스냅샷 명령들과 함께 사용한다.

또한, 실행시간 로그 필터링이 설명된다. 필터링은 불필요한 STM 연산들 모두가 컴파일 시간에 정적으로 식별될 수 있는 것은 아니기 때문에 유용한다.

일 구현에서, 여기서 설명되는 예들은 Microsoft.NET 플랫폼에 경쟁할 수 있는 성능을 가진 공통 중간 언어(CIL) 프로그램용 최적화 어헤드 오브 타임 탐색 컴파일러 및 실행시간 시스템인 Bartok에서 구현된다. 쓰레기 수집기 및 새로운 STM을 포함하는 실행시간 시스템은 CIL로 구현될 수 있다.

1.1 시맨틱스

여기서 설명되는 기술들은 아토믹 블록들의 성능에 초점을 맞춘다. 이러한 기술들을 계속 이용하는 동안 아토믹 블록들과 로킹 코드의 상호작용 및 I/O 연산들과 아토믹 블록들의 조합을 포함하는 다양한 구현은 정확한 시맨틱스에 관해 상이할 수 있다.

1.2 설계 가정들

여기서 설명되는 예들에서, 아토믹 블록들이 이용되는 방법에 대해 몇 가지 가정이 이루어진다. 이들은 여기서 설명되는 구현들에 대한 제한들을 나타내는 것은 아니며, 대신에 설명을 돕기 위한 것이다.

하나의 가정은 대부분의 트랜잭션이 성공적으로 커미트된다는 것이다. 이것은, 우선 병렬 유지 STM의 이용이 트랜잭션들이 '자발적으로' 중단되지 않을 것임을 의미하므로, 또는 프로그래머가 이해할 수 없는 충돌들 때문에(대안 구현들에서, 충돌들은 예상치 못하게 충돌할 수 있는 해시 값들에 기초하여 검출된다), 합리적인 가정이다. 이것의 일부로서, 프로그래머가 캐시들 간의 과다 데이터 이동의 비용으로 인해 충돌을 피하려는 강한 인센티브를 이미 갖고 있는 것으로 가정된다. 다충돌 연산들을 단일 스레드에 의해 관리되는 작업 큐들로 넘기는 것과 같은 기술들은 높은 가치를 유지한다.

두 번째 가정은 아토믹 블록들에서 판독들의 수가 갱신들의 수보다 많다는 것이다. 이러한 가정은 현재 프로그램들의 관찰에 의해 지지되며, 프로그램들의 트랜잭션 버전들의 개발을 시도한다. 이것은 트랜잭션 판독들의 오버헤드를 특히 낮게 유지하는 이익을 강조하는데, 판독들은 판독되는 개체의 어드레스 및 그의 헤더 워드의 내용을 로깅하는 것만을 필요로 한다.

마지막 가정은 트랜잭션 크기가 제한되지 않아야 한다는 것이다. 이것은 트랜잭션들의 길이가 증가할 때 STM 구현이 양호하게 스케일링되어야 하는 것을 시사하면서 합성성을 유지한다. 이러한 설계에서, 공간 오버헤드는 행해지는 액세스들의 수가 아니라, 트랜잭션에서 액세스되는 개체들의 볼륨에 따라 증가한다. 여기서 설명되는 예들에서, 트랜잭션들은 비공식적으로 "짧거나" "긴" 것으로 지칭된다. 짧은 트랜잭션들은 STM에 의한 어떠한 메모리 할당도 요구하지 않고 실행될 가능성이 크다. 긴 트랜잭션들은 그 실행이 GC 사이클들에 걸칠 가능성이 큰 것들이다(예를 들어, LISP 벤치마크들 중 하나를 C#으로 번역된 SPEC95 벤치마크 버전 xlisp에서 평가함).

1.3 워드 기반 STM 예

워드 기반 STM용의 하나의 통상적인 인터페이스는 아래의 두 연산 세트를 제공한다.

제1 세트는 트랜잭션들을 관리하는 데 사용되는데, TMStart는 현재의 스레드에서 트랜잭션을 개시한다. TMAbort는 현재 스레드의 트랜잭션을 중단한다. TMCommit는 현재 스레드의 트랜잭션의 커미트를 시도한다. 트랜잭션이 커미트될 수 없는 경우(예를 들어, 일 구현에서, 동시 트랜잭션이 그가 액세스한 위치들 중 하나를 갱신했기 때문에), TMCommit는 거짓을 반환하며, 현재 트랜잭션은 폐기된다. 그렇지 않은 경우, TMCommit는 참을 반환하며, 트랜잭션 동안 이루어진 임의의 갱신들이 공유 힙에 아토믹하게 전달된다. TMIsValid는 현재 스레드의 트랜잭션이 호출 시점에 커미트될 수 있는 경우에 그리고 그 경우에만 참을 반환한다. 제2 연산 세트는 데이터 액세스를 수행하는데, TMRead는 지정 위치의 현재 값, 또는 현재 트랜잭션에서 TMWrite에 의해 기입된 가장 최근의 값을 반환한다.

여기서 설명되는 기술들의 일 구현에서, STM으로 직접 프로그래밍하는 프로세스는, 컴파일러가 STM 연산들을 이용하도록 아토믹 블록들 내에 메모리 액세스들을 재기입하게 하고, 아토믹 블록에서 이루어지는 모든 메모리 액세스에 대해 TMRead 및 TMWrite가 사용되는 것을 보증하도록 피호출 메소드들의 특수 버전들을 생성하게 함으로써 자동화된다.

전술한 설계는 그의 적용성을 제한하는 많은 문제를 갖는다. 아래의 코드 예들은 이것을 설명한다. 아래에 보여지는 예 1a는 감시 노드들 this.Head 및 this.Tail 간의 연결된 리스트의 요소들을 통해 반복된다. 이것은 노드들의 Value 필드들을 합산하며, 그 결과를 this.Sum에 저장한다. 예 1b는 모든 메모리 액세스에 대해 TMRead 및 TMWrite에 대한 호출들을 자동으로 제공하는 일례를 나타낸다.

그러나, 이러한 워드 기반 시스템에서는 여러 성능 문제가 발생할 수 있다. 첫째, TMRead 및 TMWrite의 많은 구현은 모든 TMRead 및 TMWrite 연산에서 검색되는 트랜잭션 로그들을 이용한다. TMRead는 동일 트랜잭션에 의한 보다 이른 스토어들을 알아야 하며, 따라서 시험적인 갱신들을 유지하는 트랜잭션 로그를 검색한다. 이러한 검색은 대형 트랜잭션들을 지원하도록 스케일링되지 못할 수 있다. 성능은 트랜잭션 로그의 길이 및 보조 인덱스 구조들의 유효성에 의존한다. 둘째, STM 라이브러리에 대한 불투명한 호출들은 최적화를 방해한다(예를 들어, TMRead의 거동은 컴파일러에게 알려져 있지 않으므로, 루프로부터 this.Tail의 판독을 상승시키는 것은 더 이상 가능하지 않다). 마지막으로, 모놀리식 TM 연산들은 반복된 작업을 유발한다. 예를 들어, 루프에서 필드에 액세스할 때 검색이 반복된다.

1.4 분해된 직접 액세스 STM

여기서 제공되는 예들에서 이용되는 분해된 직접 액세스 STM 구현은 이러한 문제들을 해결한다. 첫 번째 문제는 트랜잭션이 힙에 대해 직접적으로 판독 및 기입 연산을 수행하여 어떠한 검색도 없이 판독이 이전 트랜잭션 스토어를 자연적으로 알 수 있도록 시스템들을 설계함으로써 해결된다. 로그들은 중단되는 트랜잭션을 롤백(roll-back)하기 위해, 그리고 액세스되는 위치들에 대한 버전 정보를 추적하기 위해 계속 필요하다. 짧은 트랜잭션들에 대해, 이들 로그는 첨부 전용이다. 따라서, 트랜잭션의 크기에 관계없이 검색은 필요하지 않다.

두 번째 문제는 컴파일 동안 조기에 TM 연산들을 도입하고 이들의 시맨틱스를 알도록 후속 분석 및 최적화 단계들을 확장함으로써 해결된다. 마지막으로, 세 번째 문제는 반복 작업을 피할 수 있도록 모놀리식 TM 연산들을 개별 단계들로 분해함으로써 해결된다. 예를 들어, 트랜잭션 로그들의 관리와 실제 데이터 액세스들을 분리하여, 로그 관리가 루프들로부터 상승되는 것을 허가한다.

이러한 인터페이스는 트랜잭션 메모리 연산들을 4개의 세트로 분해한다.

처음 두 세트는 간단하며, 현재 스레드의 트랜잭션 관리자를 얻기 위한 DTMGetTMMgr을 제공한 후, 일반적인 트랜잭션 관리 연산들을 제공한다. 세 번째 세트는 충돌 검출을 제공하는데, DTMOpenForRead 및 DTMOpenForUpdate는 지정된 개체가 판독 전용 모드로 액세스되거나 후속 갱신될 수 있음을 지시한다. 정적 필드들에 대한 액세스는 그들의 거동에 관한 버전 정보를 유지하는 대리 개체들에 의해 조정되는데, DTMAddrToSurrogate는 어드레스를 그의 대리로 맵핑한다. 마지막 세트는 중단시 갱신들을 롤백하는 데 필요한 복귀(undo) 로그를 유지한다. DTMLogFieldStore는 개체 필드들에 대한 스토어들을 처리하며, DTMLogAddrStore는 임의의 어드레스에 대한 스토어들을 처리한다.

이러한 연산들에 대한 호출들은 아토믹성을 제공하기 위해 올바르게 배열되어야 한다. 세 가지 규칙이 존재하는데, 즉 (a) 위치가 판독될 때 판독을 위해 위치가 개발되어야 하고, (b) 위치가 갱신되거나, 위치에 대해 스토어가 로깅될 때 갱신을 위해 위치가 개방되어야 하며, (c) 위치가 갱신되기 전에 위치의 이전 값이 로깅되었어야 한다. 실제로, 이것은 TMRead for a field of an object에 대한 호출이 DTMGetTMMgr, DTMOpenForRead, 및 필드 판독의 시퀀스로 분할됨을 의미한다. TMWrite는 DTMGetTMMgr, DTMOpenForUpdate, DTMLogAddrStore, 및 필드 기입이다. 정적 필드의 TMRead에 대한 호출은 DTMGetTMMgr, DTMAddrToSurrogate, DTMOpenForRead, 및 정적 필드 판독의 시퀀스로 분할된다. TMWrite는 DTMGetTMMgr, DTMAddrToSurrogate, DTMOpenForUPdate, DTMLogAddrStore, 및 정적 필드 기입이다.

아래의 예들은 분해된 직접 액세스 STM의 사용의 일례를 나타낸다. 예 1의 코드는 감시 노드들 this.Head 및 this.Tail 간의 연결된 리스트의 요소들을 통해 반복된다. 이것은 노드들의 값 필드들을 합산하며, 그 결과를 this.Sum에 저장한다. 예 2는 분해된 직접 액세스 STM을 이용하여 합산이 구현될 수 있는 방법을 나타낸다.

2. 컴파일러 최적화

제2장은 STM 연산들에 대한 지식을 갖도록 구성된 컴파일러를 이용하는 분해된 STM 연산들의 최적화를 설명한다. 본 출원에서 사용되는 "최적화하다", "최적화되다", "최적화" 등의 용어는 임의의 특정 향상도와 관련 없이 일반적으로 향상을 지칭하는 기술 용어들이라는 점에 유의해야 한다. 따라서, 다양한 시나리오에서, "최적화"는 시스템 또는 기술의 성능의 하나 이상의 양태를 향상시킬 수 있지만, 시스템 또는 기술의 모든 양태가 향상되는 것을 요구하지는 않는다. 또한, 다양한 상황에서, "최적화"는 임의의 양태의 임의의 특정 최소 또는 최대한도로의 향상을 의미할 필요는 없다. 또한, "최적화된" 시스템 또는 기술이 하나 이상의 영역에서 성능 향상을 나타낼 수 있지만, 이것은 또한 다른 영역들에서의 성능 감소를 나타낼 수도 있다. 마지막으로, "최적화"가 몇몇 상황에서는 시스템 또는 기술의 성능을 향상시킬 수 있지만, 이것은 다른 상황들에서는 성능을 감소시키는 것이 가능할 수 있다. 후술하는 특정 환경들에서, 최적화는 중복되거나 불필요한 STM 명령들 또는 로그 기입들을 제거하여 아마도 향상된 성능을 제공하지만, 이러한 최적화는 모든 가능한 중복 또는 불필요한 명령들이 제거될 것임을 의미하지 않아야 한다.

도 1은 소프트웨어 트랜잭션 메모리를 이용하여 최적화된 프로그램(120)을 생성하는 데 사용되는 컴파일러(100)의 일례를 나타내는 블록도이다. 도시된 예에서, 컴파일러(100)는 소스 코드(110)를 입력으로서 취한다. 도시된 바와 같이, 소스 코드(110)는 하나 이상의 아토믹 블록(115)을 포함한다. 전술한 바와 같이, 일 구현에서, 이러한 아토믹 블록의 포함은 STM을 이용하기를 원하는 프로그래머의 추가 프로그래밍을 필요 없게 하는데, 이들 블록은 분해된 STM 명령들을 포함하도록 컴파일러에 의해 수정된 후, 최적화된다. 도 1은 단일 소스 코드를 도시하고 있지만, 이것은 단지 도시의 간략화를 위한 것이며, 여기서 설명되는 기술들 및 시스템들은 함께 컴파일되는 다중 소스 코드 파일들은 물론, 이미 컴파일된 코드를 사용하는 소스 코드에도 적용된다는 것을 인식해야 한다. 또한, 다양한 구현에서, C++, C#, 자바, C 등을 포함하는 상이한 코드 언어들이 사용되며, 또한 다양한 구현에서, 해석된 언어들은 또한 최적화될 수 있다. 도시된 예에서, 이러한 최적화는 컴파일러에 통합되는 STM 최적화들(150)에 의해 제공되는데, 이러한 통합의 추가 상세는 후술한다. 컴파일 및 최적화 후에, 소프트웨어 트랜잭션 메모리를 이용하는 최적화된 프로그램(120)이 생성된다. 이러한 최적화된 프로그램의 실행시간 연산들의 추가 상세는 아래에서 더 상세히 설명된다. 또한, 도시된 구현은 실행 전에 실행가능 파일로의 컴파일을 나타내지만, 여기서 설명되는 기술들의 대안 구현들은 실행 전에 또는 실행과 동시에 프로그램들을 즉시 컴파일 및 최적화할 수 있다.

도 2는 도 1의 컴파일러(100)의 예시적인 컴포넌트들을 나타내는 블록도이다. 도 2는 컴파일러를 통하는 예시적인 연산 경로를 나타낸다. 도 2가 특정 모듈들을 개별적으로 도시하고 있지만, 다양한 구현에서 모듈들은 병합되거나, 다양한 조합으로 분할될 수 있음을 알아야 한다. 경로는 소스 코드(110)를 수신하고 그로부터 중간 표현(230)을 생성하는 제1 컴파일러 모듈(220)에서 시작된다. 일 구현에서, 이 IR은 제어 흐름 그래프("CFG")의 형태를 취하는데, 이는 IR이 여기서 설명되는 최적화 기술들에 의해 쉽게 조작되는 것을 허가한다.

이어서, IR(230)은 최적화된 IR(250)을 생성하기 위해 최적화 모듈(240)에 의해 수정된다. 최적화 모듈(240)의 연산에서, 통상의 컴파일러 최적화들은 저 레벨 및 고 레벨 STM 고유 최적화들로 확장된다. 이러한 최적화들의 예는 아래에서 더 상세히 설명된다. 마지막으로, 최적화된 IR(250)은 제2 컴파일러 모듈(260)에 의해 도 1의 최적화된 프로그램(120)과 같은 실행가능 코드로 컴파일된다.

도 3은 STM을 이용하여 프로그램을 컴파일하고 실행하기 위한 예시적인 프로세스(300)의 흐름도이다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 프로세스는 블록 320에서 시작되어, 트랜잭션 메모리 블록들(도 1의 아토믹 블록들 등)을 포함하는 소스 코드가 수신된다. 대안 구현에서, 소스 코드는 트랜잭션 메모리 블록들을 포함하지 않을 수 있지만, 대신에 전술한 워드 기반 또는 분해된 명령들과 같은 개별 소프트웨어 트랜잭션 메모리 명령들을 포함할 것이다. 이어서, 블록 340에서, 소스 코드는 실행가능 프로그램으로 컴파일된다. 컴파일의 특정 예들이 아래에서 더 상세히 설명된다. 마지막으로, 블록 360에서, 실행가능 프로그램이 실행된다.

도 4는 트랜잭션 메모리 블록들을 포함하는 소스 코드를 컴파일하기 위한 예시적인 프로세스(400)의 흐름도이다. 프로세스(400)는 도 3의 블록 340에 대응한다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 프로세스는 블록 420에서 시작되어, 소프트웨어 트랜잭션 메모리 명령들이 컴파일러(100)에 의해 각각의 아토믹 블록 내로 삽입된다. 일 구현에서, 이러한 삽입은 블록 내의 판독 또는 기입의 모든 인스턴스 주변에 적절한 워드 기반 판독 및 기입 STM 명령들을 삽입함으로써 수행된다. 다른 구현에서, 프로그래머가 그 자신의 STM 명령들을 삽입하기로 결정한 경우, 블록 420의 프로세스는 생략될 수 있다.

이어서, 블록 440에서, 워드 기반 STM 명령들은 컴파일러(100)에 의해 분해된 명령들로 대체된다. 일 구현에서, 컴파일러에 의해 수신된 소스 코드가 이미 분해된 명령들을 포함하는 경우, 블록 440의 프로세스는 생략된다. 또한, 몇몇 구현에서, 특히 블록 420 및 440의 프로세스들은 아토믹 블록의 수신에 응답하여 분해된 STM 명령들을 직접 삽입하도록 조합될 수 있다. 위의 예 2는 블록 440의 프로세스의 연산 후에 하나의 코드가 어떻게 보일 수 있는지를 나타낸다.

블록 440의 프로세스의 다른 구현에서, 컴파일러는 로그 연산들을 분해하여 다수의 연산을 통한 로그 관리 작업의 비용의 분할 상환을 허가함으로써 로그 관리 비용을 더 줄인다. 구체적으로, 일 구현에서, DTMOpen* 및 DTMLog* 연산들은 현재 어레이 내에 공간이 존재한다는 검사로부터 시작된다. DTMOpenForRead에 대해, 이것은 코드의 고속 경로 버전에서 수행되어야 하는 유일한 검사이다. 이러한 검사들의 비용을 상환하기 위하여, 컴파일러는 주어진 로그 내에 얼마나 많은 슬롯을 예약해야 하는지를 지시하는 정수를 취하는 새로운 연산 EnsureLogMemory를 이용한다. 따라서, DTMOpen* 및 DTMLog* 연산들의 특수화된 분해 버전들은 공간이 존재하는 것으로 가정할 수 있다. 일 구현에서, 실행시간 부기를 줄이기 위하여, EnsureLogMemory 연산들은 더해지지 않으며, 2개의 연속 연산은 총계가 아니라 요청된 최대를 예약한다. 간략화를 위해, 일 구현은 호출 또는 백 에지 후에 예약 공간이 요구되는 특수화된 연산들을 배치하지 않는다. 다른 구현에서, 예약들은 각각의 기본 블록 내의 호출들 간의 모든 연산에 대해 조합된다. 다른 구현에서, 가능한 한 일찍 간절히 공간을 예약하기 위해 역방향 분석이 이용되며, 이는 모든 호출 및 루프 헤더에서 중지되도록 강제된다. 이것은 보다 많은 예약을 조합하는 이점을 갖지만, 예약 연산을 필요로 하지 않는 경로 상에 예약 연산을 도입할 수 있다.

블록 460에서, 컴파일러는 강한 아토믹성을 위한 연산들의 도입, 불필요한 STM 연산들의 이동 및 제거, 및 새로 할당된 개체들에 대한 로그 연산들의 제거를 포함하는 고 레벨 STM 최적화들을 수행한다. 이 프로세스는 아래에서 더 상세히 설명된다. 마지막으로, 블록 480에서, STM 명령들을 포함하는 프로그램이 최적화된다. 도 4의 프로세스는 블록들 460 및 480에서의 다른 최적화들이 이어지는 고 레벨 최적화들을 도시하고, 최적화들의 반복은 도시하지 않지만, 몇몇 구현에서, 블록들 460 및 480의 프로세스들 또는 이들의 서브 프로세스들은 도시된 것과 다른 순서로 수행될 수 있고, 반복될 수 있다. 반복에 대한 하나의 이유는 소정의 최적화들이 다른 최적화들을 위한 기회를 제공한다는 점이다. 따라서, 최적화들을 반복 수행하여 이들이 제공할 수 있는 기회를 이용하는 것이 바람직할 수 있다.

도 5는 STM 명령들 상에 고 레벨 최적화들을 수행하기 위한 예시적인 프로세스(500)의 흐름도이다. 프로세스(500)는 도 4의 블록 460에 대응한다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 일 구현에서, 프로세스(500)는 고 레벨 최적화들에 의해 추가되는 연산들이 컴파일러에 의해 더 최적화될 수 있도록 하기 위해 후술하는 프로세스(600)의 컴파일러 최적화 전에 수행된다. 프로세스는 블록 520에서 시작되어, 컴파일러는 강한 아토믹성을 위한 연산들을 도입한다. 이어서, 블록 540에서, 후속 최적화 동안 개방 연산들의 후속 제거를 허가하기 위하여, 갱신을 위해 개체들을 개방하는 연산들이 이어지는 판독을 위해 동일 개체들을 개방하는 연산들이 갱신을 위한 개방 연산들(open-for-update operations)로 대체된다. 일 구현에서, 갱신을 위한 개방 연산들이 이어지는 판독을 위한 개방 연산들은 갱신을 위한 판독 업그레이드들이라고 하며, 블록 540의 프로세스는 이러한 업그레이드들을 제거한다. 이어서, 블록 560에서, 도 6의 프로세스에서 보다 큰 최적화들을 제공하기 위하여, 분해된 STM 연산들이 프로시저 호출들의 주위로 이동된다. 마지막으로, 블록 580에서, 개체들이 로깅되는 트랜잭션들에서 새로 할당되는 개체들에 대한 로깅 연산들이 필요 없는 로그 연산 호출들을 방지하기 위해 제거된다. 이러한 프로세스들 각각의 특정 예들은 도 7-12와 관련하여 아래에 더 상세히 설명된다.

2.1. 분해된 코드 상의 컴파일러 최적화

도 6은 STM 명령들 상의 최적화를 수행하기 위한 예시적인 프로세스(600)의 흐름도이다. 프로세스(600)는 도 4의 블록 480에 대응한다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 또한, 도시된 구현은 각각의 액션이 한 번 수행되는 예를 제공하지만, 대안 구현들에서, 액션들은 반복될 수 있다. 따라서, 예를 들어, 후술하는 공통 하위 표현식 제거 액션은 코드 이동 최적화들이 수행된 후에 재차 수행될 수 있다. 도 6은 비 STM 명령들의 최적화는 도시하고 있지 않지만, 이것은 도시의 간략화를 위한 것이며, 여기서 설명되는 프로세스들에 대한 어떠한 제한도 나타내지 않는다.

프로세스는 블록 620에서 시작되어, STM 명령들의 수정에 대한 제한들이 생성된다. 일 구현에서, 이러한 제한들은 적어도, 호출들의 시퀀스에서 기초가 되는 아토믹성을 위한 것들이다. 따라서, 세 가지 규칙이 존재하는데, 즉 (a) 위치가 판독될 때 판독을 위해 위치가 개방되어야 하고, (b) 위치가 갱신되거나, 위치에 대해 스토어가 로깅될 때 갱신을 위해 위치가 개방되어야 하며, (c)위치가 갱신되기 전에 위치의 이전 값이 로깅되었어야 한다.

이들 규칙은 다수의 방법을 이용하여 구현될 수 있다. 하나의 방법에서, 컴파일러는 다양한 하우스키핑 수단을 통해 컴파일 동안 제한들의 추적을 유지한다. 이것은 컴파일 프로세스를 곧 복잡하게 하므로, 다른 구현에서는 제한들이 위반되는 것을 방지하기 위해 CFG가 수정될 수 있다. 이러한 하나의 방법은 후속 명령들에 대한 입력 변수들이 되는 명령들에 대한 더미 출력 변수들을 생성함으로써 호출 지시를 강요하는 STM 명령들 간의 더미 변수들을 이용하여 데이터 종속성을 도입하는 것이다. 따라서, (일반 명령들을 사용하여) 다음과 같이 보이는 IR는

로 된다.

이어서, 블록 640에서, STM 명령들 상에서 공통 하위 표현식 제거("CSE")가 수행되고, 블록 660에서 명령들 상의 중복 로드-스토어 제거 및 블록 680에서 코드 이동 최적화가 이어진다.

일례에서, 이러한 최적화들은 DTMGetTMMgr 연산 상에서 수행될 수 있는데, 이는 이것이 상수이고, 따라서 CSE를 위한 기회를 제공하기 때문이다. 마찬가지로, DTMOpenForRead, DTMOpenForUpdate, DTMAddrToSurrogate 및 DTMLog* 연산들은 트랜잭션 내에서 등멱이므로, 이들은 또한 CSE 또는 코드 이동에 적합하다. 이러한 최적화에 대한 하나의 제한은 일 구현에서 코드 이동이 트랜잭션 경계들을 넘어 확장될 수 없다는 것이다. 다른 구현에서, CSE는 DTMOpenForUpdate 후에 발생하는 DTMOpenForRead 명령들에 대한 제거를 제공하도록 확장된다. 이러한 최적화는 갱신 액세스가 판독 액세스를 포함하므로 수행될 수 있다.

다른 구현들에서, CSE는 중첩된 트랜잭션들 간의 연산들 상에서 수행될 수 있다. 따라서, 일례에서, 중첩된 트랜잭션 내의 DTMOpenForRead 연산은 외측 트랜잭션 내의 DTMOpenForRead 또는 DTMOpenForUpdate에 포함되며, 따라서 제거될 수 있다. 다른 예에서, 중첩된 트랜잭션 내의 DTMOpenForUpdate는 외측 트랜잭션 내의 DTMOpenForUpdate에 포함되며, 제거된다.

다른 구현에서, DTMGetTMMgr 연산은 스레드 단위 Thread 개체로부터 스레드에 대한 현재 트랜잭션 관리자를 페치함으로써(그리고 필요에 따라 트랜잭션 관리자를 생성함으로써) 구현될 수 있다. 따라서, Bartok 컴파일러는 또한 GetCurrentThread 명령을 코드 이동에 종속하는 상수 연산으로서 처리할 수 있다.

일례로서, 상기 프로세스들의 수행 후, 예 2의 코드는 아래의 보다 효율적인 코드로 간략화된다.

2.2. 고 레벨 STM 최적화

2.2.1 강한 아토믹성의 구현

전술한 기술들은 하나의 아토믹 블록에서의 메모리 액세스들이 다른 아토믹 블록에서의 액세스들에 관해 불가분하게 발생하는 "아토믹" 블록들을 구축하는 데 이용될 수 있다. 그러나, 하나의 스레드에 의해 실행되는 "아토믹" 블록은 다른 스레드가 "아토믹" 블록을 사용하지 않고 충돌 메모리 액세스를 수행할 때에는 불가분하게 실행되는 것으로 보이지 않을 수 있다. 이러한 특징을 가진 설계들은 "약한 아토믹성"을 제공하는 것으로 일컬어질 수 있다.

여기서 설명되는 기술들의 하나의 구현은 아토믹 블록들이 다른 아토믹 블록들에서 행해지는 메모리 액세스들만이 아니라 모든 메모리 액세스에 관해 불가분하게 실행되는 것으로 보이는 "강한 아토믹성"을 제공하는 방법과 관련된다.

기본 구현은 (a) 임의의 아토믹 블록 외부에서 발생하는 공유 메모리에 대한 모든 액세스를 식별하고, (b) 이들을 짧은 아토믹 블록들로서 재기입함으로써 강한 아토믹성에 대한 지원을 갖는 전술한 STM을 확장한다.

예를 들어, 프로그램이 필드 "o1.x"의 내용으로부터 판독하여 그 결과를 필드 "o2.x"에 저장하는 것으로 가정한다. 이것은 최초에 컴파일러의 중간 표현(IR) 내의 2개의 명령에 의해 표현될 것이다.

기본 구현은 이들을 다음과 같은 코드로 확장한다.

(몇몇 구현에서, 기입되는 실제 코드는 더 복잡한데, 이는 커미트 연산들 C1 또는 C2 동안 충돌이 존재하는 경우에 실제 코드가 L1 또는 L2로부터 트랜잭션들을 재실행하기 위해 코드 경로들을 또한 포함해야 하기 때문이다. 이 코드에 대한 정확한 상세는 STM 연산들이 IR에서 어떻게 표현되는가에 따라 달라질 것이다.)

기본 형태는 강한 아토믹성을 제공하지만, 최초 필드 액세스들의 비용을 넘는 트랜잭션 개시, 트랜잭션 커미트, 판독을 위한 개방, 갱신을 위한 개방, 및 로그 연산들의 추가 비용으로 인해 불완전하게 수행할 것이다.

강한 아토믹성 구현을 계속 제공하면서 효율을 향상시키기 위하여, 여기서 설명되는 기술들의 하나의 구현은 특수화된 IR 연산들을 이용하여, 단일 메모리 위치에만 액세스하는 짧은 트랜잭션들의 수행을 가속화한다.

고려해야 할 두 가지 사례, 즉 단일 위치로부터 판독하는 트랜잭션들 및 단일 위치를 갱신하는 트랜잭션들(단일 위치에 대해 판독-수정-기입 연산들을 수행하는 트랜잭션들 포함)이 존재한다. 양 사례는 STM 워드의 검사를 수반하는데, 이는 아래에 더 상세히 설명된다. 제1 사례는 (a) 관련 개체에 대한 STM 워드를 판독하고, (b) 필드를 판독하고, (c) STM 워드를 재판독하고, 판독된 값이 (a)에서의 그것과 매칭되었고 그 값이 동시 충돌 액세스가 존재하였음을 지시하지 않는다는 것을 검사함으로써 확장된 IR 내에 표현된다. 제2 사례는 (a) 관련 개체에 대한 STM 워드를 갱신하고-이는 STM 워드가 비 트랜잭션 갱신에 종속함을 나타냄-, (b) 필드를 갱신하고, (c) STM 워드를 한 번 더 갱신함-이는 STM 워드가 더 이상 비 트랜잭션 갱신에 종속하지 않음을 나타냄-으로써 확장된 IR 내에 표현된다.

따라서, IR은 일례로 다음과 같이 보인다.

이 구현은 전술한 STM 구현과의 두 가지 차이를 포함한다. 첫째는 전술한 STM 구현과 달리 트랜잭션 로그들이 아니라 지역 변수들에서 임시 저장이 발견된다는 점이다. 이것은 변수들이 그들에 대한 액세스를 빠르게 하기 위해 프로세서 레지스터들 내에 할당될 수 있음을 의미한다. 두 번째 차이는 L2에서 시작하는 트랜잭션이 중단될 수 없고, 따라서 "o2.x"에 겹쳐 쓰인 값을 로깅할 필요가 없다는 점이다.

또 다른 강한 아토믹성의 구현에서, 컴파일러는 이러한 방식으로 확장되어야 하는 필드들의 수를 제한하기 위해 추가 최적화를 수행한다. 일례에서, 컴파일러는 아토믹 블록에서 기입될 수 있는 모든 필드를 식별하기 위해 유형 기반 분석을 수행한다. 아토믹 블록들에서의 액세스에 결코 종속하지 않도록 보증되는 임의의 다른 필드들은 직접 액세스될 수 있으며, 따라서 강한 아토믹성 연산들이 그들 주위에 삽입되는 것을 요구하지 않을 것이다.

도 7은 강한 아토믹성을 구현하기 위한 연산들을 도입하기 위한 예시적인 프로세스(700)의 흐름도이다. 프로세스(700)는 도 5의 블록 520에 대응한다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 프로세스는 블록 710에서 개시되어, 아토믹 블록에서 액세스될 수 있는 필드들을 결정하기 위해 유형 분석이 수행된다. 전술한 바와 같이, 일 구현에서, 이것은 충돌을 유발할 수 없는 메모리 액세스들에 대한 강한 아토믹성 연산들의 불필요한 삽입을 피하기 위해 수행된다. 이어서, 블록 720에서, 블록 710에서 결정된 필드들을 이용하여, 아토믹 블록에 포함된 필드에 액세스할 수 있는 프로그램 내의 메모리 액세스를 찾는다. 대안 구현에서, 블록 710의 프로세스는 생략될 수 있으며, 블록 720의 프로세스는 강한 아토믹성 연산들의 삽입을 위해 아토믹 블록들 외부의 모든 메모리 액세스를 찾을 수 있다.

이어서, 프로세스는 판정 블록 725로 계속되어, 컴파일러는 블록 720에서 찾은 액세스가 판독 액세스인지 또는 갱신 액세스인지를 판정한다. 액세스가 판독 액세스인 경우, 프로세스는 블록 730으로 계속되어, 판독을 위한 개방 명령이 액세스 전에 삽입된다. 일 구현에서, 이 명령은 STM 워드를 수신할 수 있을 때까지 차단되며, 따라서 메모리 액세스가 액세스되고 있는 필드를 적절히 판독할 수 있는 것을 보장하도록 구성된다. 다른 구현에서, 연산은 차단되지 않지만, 메모리 액세스가 검사되지 않는 경우에는 메모리 액세스 후에 루프가 생성된다. 이어서, 블록 740에서, 판독 액세스 동안에 STM 워드가 판독되고 있는 필드에 대한 변경을 지시하지 않았음을 보장하기 위해 메모리 액세스 후에 검사 명령이 삽입된다. 위에 제공된 구현에서, 이것은 블록 730에서 STM 워드를 수신하고, 블록 740에서 STM 워드를 검사 연산에 전달함으로써 행해지는데, 이것은 또한 코드 최적화가 강한 아토믹성 연산들의 순서를 재배열하는 것을 방해하는 데이터 종속성을 생성한다.

그러나, 블록 725에서 액세스가 갱신 액세스인 것으로 판정되면, 프로세스는 블록 750으로 계속되어, 액세스 전에 갱신을 위한 개방 명령이 삽입된다. 일 구현에서, 이 명령은 다른 액세스들을 방지하여 강한 아토믹성을 제공하기 위해 액세스되고 있는 개체로부터 STM 워드를 수정하도록 구성된다. 이어서, 블록 760에서, 메모리 액세스에서 수행되는 갱신을 커미트하기 위해 메모리 액세스 후에 커미트 명령이 삽입된다. 일 구현에서, 액세스되는 개체에 대한 버전 번호가 변경된다. 다른 구현에서는 그렇지 않다. 이어서, 판정 블록 765에서, 컴파일러는 추가적인 비 아토믹 메모리 액세스들이 존재하는지를 판정한다. 그러한 경우, 프로세스가 반복된다. 그렇지 않은 경우, 프로세스가 종료된다.

2.2.2 판독/갱신 업그레이드들의 제거

STM 컴파일러의 다양한 구현에 의해 수행되는 다른 하나의 고 레벨 최적화는 DTMOpenForRead 연산에 이어서 DTMOpenForUpdate 연산이 수행될 때 발생하는 불필요한 로깅을 방지하는 것이다. 여기서 설명되는 기술들에 고유한 하나의 설계 가정은 판독이 기입보다 일반적이라는 것인데, 이는 이 기술들이 개별 DTMOpenForUpdate 및 DTMOpenForRead 연산들을 사용하며, 판독을 위한 개방 명령이 보다 빠르게 완료될 수 있는 이유이다. 그러나, 때때로 개체들은 (표준적인 예인 "obj.field++")로부터 판독된 후 그에 기입된다. 이 경우, 개방 연산들을 가진 IR은 다음과 같이 보일 것이다.

프로그램이 판독을 위한 개방 포인트에 도달하면, 프로그램은 갱신을 위한 개방 포인트에 도달하여 우선 예외들을 무시할 것이라는 것을 알 수 있다. 동일 개체에 대해 갱신을 위한 개방이 판독을 위한 개방을 포함하므로, 판독을 위한 개방 연산은 제거된다. 이것은 일 구현에서 판독/갱신 업그레이드로서 알려진다. 갱신을 위한 개방 연산을 보다 일찍 간단히 수행하는 것이 보다 효율적이다.

따라서, 일 구현에서, 컴파일러는 판독/갱신 업그레이드들이 발견될 때 이들을 제거한다. 일반적으로, 이것은 간단한 데이터 흐름 분석을 통해 기본 블록 내의 컴파일러에 의해 처리될 수 있으며, 따라서 DTMOpenForRead 연산들은 DTMOpenForUpdate가 이어지는 경우에는 업그레이드될 수 있다. 다른 일반적인 경우에, DTMOpenForUpdate 연산들은 (관련 변수들에 대한 스토어들을 개재하지 않고) 모든 비 예외 경로가 동일 DTMOpenForUpdate를 수행하는 모든 기본 블록의 시작에 간단히 삽입된다. 이어서, CSE는 동일 개체에 대한 여분의 DTMOpenForUpdate 연산들은 물론, 임의의 후속 DTMOpenForRead 연산들을 제거하려고 시도한다.

도 8은 불필요한 판독/갱신 업그레이드들을 제거하기 위한 예시적인 프로세스(800)의 흐름도이다. 프로세스(800)는 도 5의 블록 540에 대응한다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 프로세스는 블록 810에서 시작되어, 컴파일러가 동일 참조에 대한 갱신을 위한 개방 연산들이 항상 이어지는 판독을 위한 개방 연산들을 식별한다. 여기의 예들은 개체 포인터들을 이용하지만, 불필요한 판독/갱신 업그레이드들을 제거하기 위한 설명되는 기술들은 또한 내부 포인터들 및 정적 필드들에 대한 제거를 구현한다는 점에 유의한다. 컴파일러는 개방 연산들이 동일 개체(또는 정적 필드들의 일 구현의 경우에는 대리 개체)에 대한 것임을 결정할 필요가 있다.

일 구현에서, 분석은 개체 참조 또는 내부 포인터가 동일 지역 변수이고 변수가 연산들 사이에서 갱신되지 않을 것을 요구한다. 이러한 구현은 할당을 통한 업그레이드의 제거를 행하지 못할 수 있지만, 다른 구현들은 또한 할당들을 분석한다. 다른 구현에서, 정적 필드들(또는 변수들)은 대리 개체들에 대한 개방 연산들을 통해 제어되는데, 이는 단일 대리 개체가 모든 정적 필드를 제어할 때 2개의 상이한 정적 필드 사이에서 업그레이드들이 제거되는 것을 가능하게 한다. 블록 810의 프로세스의 예시적인 프로세스가 도 9와 관련하여 아래에 더 상세히 설명된다.

이어서, 블록 820에서, 블록 810에서 식별된 판독을 위한 개방 연산들은 동일 참조에 대한 갱신을 위한 개방 연산들로 대체된다. 이어서, 블록 830에서, 중복적인 갱신을 위한 개방 연산들이 제거된다. 일 구현에서, 이것은 블록 820의 프로세스 직후에 수행되는 것이 아니라, 대신에 CSE와 같은 도 6에 대해 설명된 컴파일러 최적화들에 의해 수행된다.

판독/갱신 업그레이드 제거 분석의 제1 전형적인 구현은 기본 블록들 내의 업그레이드들을 제거한다. 따라서, 컴파일러는 전체 프로그램 내의 각각의 기본 블록을 주시하고, 각각에 대해 판독을 위한 개방 연산들을 찾기 위해 스캔한다. 첫 번째 것이 발견될 때, 컴파일러는 미리 스캔하여(scan ahead), 개방되고 있는 개체를 지시하는 변수에 대한 갱신을 위한 개방 연산 또는 할당들을 찾는다. 갱신을 위한 개방이 먼저 발생하는 경우, 컴파일러는 판독을 위한 개방을 갱신을 위한 개방 연산으로 바꾸고 최초의 갱신을 위한 개방을 삭제한다. 변수가 갱신되면, 그 검색은 포기된다. 대안 구현에서, 컴파일러는 판독을 위한 개방 연산들을 검색하기 위해 갱신을 위한 개방 연산들로부터 역방향으로 스캔할 수 있다.

도 9는 갱신을 위한 개방 연산들에 항상 포함되는 식별된 판독을 위한 개방 연산들을 제거하기 위한 제2 예시 프로세스(900)의 흐름도이다. 프로세스(900)는 도 8의 블록 810에 대응한다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다.

도 9의 프로세스는 표준 역방향 데이터 흐름 분석을 이용한다. 이 분석에서, 컴파일러는 미래에 갱신을 위해 명확히 개방되는 개체들의 세트를 모든 프로그램 포인트에서 계산한다. 다양한 구현에서, 도 9의 프로세스는 프로그램 내의 모든 기본 블록 각각에 대해, 또는 기본 블록들의 서브 세트들에 대해 수행된다. 프로세스는 블록 910에서 시작되어, 명확히 갱신되는 개체들의 지시들을 포함하는 세트들이 기본 블록 경계에서 생성된다. 블록 920에서, 기본 블록 내의 모든 변수가 세트에 추가된다. 이어서, 블록 930에서, 기본 블록 내의 최종 명령을 검사함으로써 기본 블록 내의 명령들의 분석이 시작된다. 판정 블록 935에서, 컴파일러는 명령의 형태를 고려한다. 명령이 할당(예를 들어, "x=...")인 경우, 블록 940에서, 세트에 할당된 변수가 세트로부터 제거된다. 그러나, 명령이 갱신을 위한 개방 명령인 경우, 블록 950에서, 명령에 의해 개방된 변수가 세트에 추가된다.

어느 경우에나, 또는 명령이 다른 유형인 경우, 컴파일러는 판정 블록 955로 이동하여, 기본 블록 내에 추가 명령들이 존재하는지를 판정한다. 그러한 경우, 블록 960에서, 컴파일러는 제어 흐름 그래프를 통해 역방향으로 이동하여, 제어 흐름 그래프 내의 다음 명령을 발견하고, 프로세스가 반복된다. 컴파일러가 판정 블록 955에서 명령들이 더 이상 존재하지 않는 것으로 판정하는 경우, 기본 블록의 시작에 도달하였다. 컴파일러가 블록의 시작에 도달한 때, 블록 970에서 컴파일러는 그 블록의 선행 블록들(즉, 현재 블록으로 점프할 수 있는 블록들)을 발견하고, 세트를 이들 선행 블록 각각의 끝에 저장된 세트들과 교차시킨다. 일 구현에서, 도 9의 프로세스는 더 이상 아무것도 변경되지 않을 때까지 반복되어, 각 블록의 끝에 현재 세트를 제공한다. 컴파일러는 동일한 방식으로 세트를 갱신하는 블록을 통해 역방향으로 이동하여, 각 프로그램 포인트에 대한 세트를 얻을 수 있다.

이 시점에서, "미래에 갱신을 위해 개방되어야 하는" 세트 내의 변수들이 블록 810의 목적을 위해 식별된다. 이어서, 일 구현에서, 갱신을 위한 개방 연산들이 이들 변수 각각에 대해 추가되어, CSE가 나중에 여분의 갱신을 위한 개방 연산들을 제거하는 것을 가능하게 한다. 다른 구현에서, CSE 최적화가 이어지는 갱신을 위한 개방 명령들의 적극적인 추가 대신에 부분 중복("PRE")이 이용된다. 이것은 보다 일반적인 해결책이며, 몇몇 경로들 상의 보다 적은 개방 명령들을 갖는 코드를 생성할 수 있다.

일 구현에서, 전술한 분석들은, 예외들이 발생하지 않고, 따라서 예외 에지들을 무시하며, 예외들이 버려지지 않을 경우에 미래에 갱신을 위해 명확히 개방되는 개체들의 세트를 계산하는 것을 가정한다. 이것은 예외들이 일반적인 사례가 아니기 때문이다. 이러한 정밀도의 손실은 정확도에 영향을 미치지 않는다. 그러나, 대안 구현들은 정밀한 결과들을 산출하기 위해 예외 에지들을 고려하도록 확장될 수 있다.

또한, 대안 구현들에서, 전술한 분석들은 다른 코드들을 무시하도록 수정될 수 있다. 이것은 무시된 코드가 분석되는 코드에 비해 상대적으로 드물게 실행됨을 지시하는 발견적 지도법(heuristices)을 이용하여 행해질 수 있다. 일 구현에서, 이러한 발견적 지도법은 정적으로 결정되며, 다른 구현에서 이것은 프로파일 정보로부터 결정된다.

일례로서, 상기 프로세스들의 수행 후, 예 3의 코드가 아래와 같은 보다 효율적인 코드로 간략화된다.

2.2.3 프로시저 호출들의 존재 하의 연산들의 이동

많은 기존 컴파일러 최적화들은, 기술들이 일반적으로 너무 비싸서 전체 프로그램의 그래프에 적용될 수 없으므로, 단지 함수들 내의 코드를 비교하고, 제거하고, 이동시킬 수 있다. 그러나, 프로시저 경계들 간에 STM 연산들을 이동시키는 고 레벨 STM 최적화를 통해, 이들 최적화는 보다 효율적으로 수행될 수 있다.

일례로서, 아래의 코드가 주어질 때,

Foo는 갱신을 위해 그의 파라미터에 의해 참조되는 개체를 항상 개방할 것이 명백하다. Foo의 호출자는 또한 (전술한 바와 같은) 개체를 개방하거나, 루프(또는 다수의 다른 것들) 내에서 Foo를 호출하고 있을 수 있다. 그러나, 프로시저 호출은 호출자 내의 코드를 이용한 Foo의 액션들의 분석/최적화를 방해한다. 이러한 최적화는 호출 장벽을 통해 개방 연산을 이동시켜, 다른 최적화들을 위한 보다 많은 기회를 생성한다. 호출자가 그에게 이동되는 연산을 이미 행했을 수 있을 때, CSE는 명백한 후보이다. 다른 비 트랜잭션 고유 최적화들도 개선될 수 있다(예를 들어, 동일 개체가 루프 내의 함수로 반복 전달되는 경우, 개방은 루프로부터 상승될 수 있다).

일례에서, 이러한 최적화는 DTMGetTMMgr 및 DTMOpenFor* 연산들에 대해 구현된다. 대안 구현들에서, 최적화는 메소드가 호출되는 경우에 발생해야 하는 다른 연산들에 대해 수행될 수 있다. 또한, 대안 구현들에서, 최적화는 메소드가 호출되는 경우에 일반적으로 발생하는 연산들에 대해 수행될 수 있는데, 이는 건전함을 잃지 않고 일반 사례들에서의 보다 양호한 성능을 위해 일반적이 아닌 사례들에서의 정밀도 및 성능을 희생시킨다. 일 구현에서, 컴파일러는 비 가상("직접"이라고도 함) 호출들에 대한 최적화를 수행하는데, 이것은 "비 가상화된" 가상 호출들을 포함한다(예를 들어, 단일 호출 타겟만이 존재하는 것으로 결정하고, 가상 호출을 직접 호출로 대체함).

도 10은 STM 연산들을 메소드 경계들을 통해 이동시킴으로써 이들을 최적화하기 위한 예시적인 프로세스(1000)의 흐름도이다. 프로세스(1000)는 도 5의 블록 560에 대응한다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 프로세스는 블록 1010에서 시작되어, 메소드의 외부로 이동될 수 있는 연산들을 포함하는 메소드들을 찾는다. 이어서, 블록 1020에서, 메소드는 연산이 메소드의 외부에서 수행되는 것을 허가하는 메소드의 버전을 생성하도록 복제된다. 연산이 결과를 제공하면, 블록 1020의 프로세스는 또한 인수를 복제된 메소드에 추가하여 결과가 그에게 전달되게 할 수 있다.

이어서, 블록 1030에서, 연산은 복제된 메소드로부터 메소드에 대한 하나 이상의 호출 사이트로 이동된다. 대안 구현에서는, 메소드를 정확히 복제하고 연산을 제거하는 것이 아니라, 연산의 이동 없이 복제된 메소드가 생성된다. 이어서, 마지막으로 블록 1040에서, 최초 메소드에 대한 호출들이 복제된 메소드로 대체된다. 대체 호출들의 일 구현에서, 복제된 메소드들에 의해 사용되는 추가 인수들이 포함된다. 추가 인수들의 예는 아래에 보여진다.

호출들의 대체의 다른 구현에서, 컴파일러는 그가 복제한 메소드들의 세트 및 이 메소드들에서 이들의 복제된(특수화된) 버전들로의 맵핑을 유지한다. 이어서, 컴파일러는 프로그램 내의 모든 메소드를 다시 스캔하여 호출들을 대체한다. 몇몇 경우에, 이러한 기술은 함수의 최초 버전을 완전히 제거한다. 그러나, 몇몇 경우에는(예를 들어, 함수의 어드레스가 취해지는 경우), 특수화되지 않은 버전에 대한 호출들이 계속 존재할 것이며, 이것은 제거될 수 없다.

상이한 연산들은 메소드들이 상이한 방식으로 복제되게 한다. 일례에서, 메소드가 GetTxMgr을 포함하는 경우, 컴파일러는 메소드를 복제하고, 트랜잭션 관리자를 수신하도록 여분의 파라미터를 추가하며, GetTxMgr의 모든 사건을 그 파라미터로 대체한다.

이 예에서, 메소드에 대한 호출들은 트랜잭션 관리자를 포함하는 추가 인수를 갖는 복제된 메소드에 대한 호출들로 변경된다.

다른 예에서, (트랜잭션 관리자)에 기초하여 특수화된 복제를 추적하고 생성하는 단일 특성을 갖는 대신, 많은 특성(각각의 파라미터 및 각각의 정적 대리)이 존재한다. 예를 들면, 다음과 같다.

이 예에서, 컴파일러는 호출자가 obj1 및 obj3를(그러나 obj2은 필수가 아님) 적절히 개방할 것을 기대하는 특수화된 버전을 생성하기를 원한다. 일 구현에서, 이것은 전술한 "미래의 소정 시점에서 갱신을 위해 개방되어야 하는" 분석을 블록 1010의 프로세스의 일부로서 수행함으로써 행해진다. 여기서, 분석은 파라미터들 및 정적 대리들만을 추적하지만, 또한 "판독을 위한 개방"은 물론, "갱신을 위한 개방" 연산들을 행하도록 확장된다. 이어서, 컴파일러는 함수의 루트에서 세트들을 분석한다. 이들이 비어 있지 않은 경우, 컴파일러는 적절한 개방 연산들을 이리저리 이동시키는 것을 제외하는 대신에 전술한 바와 같이 메소드를 복제한다. 컴파일러는 다른 최적화들을 보기 위해 개방될 것으로 기대되는 파라미터들(및 판독 또는 갱신의 여부)을 복제된 함수 상에 저장한다.

2.2.4 새로 할당된 개체들에 대한 로그 연산들의 감소

최종 고 레벨 최적화는 트랜잭션 내에서 새로 할당된 개체들에 대한 트랜잭션에서 로그 연산들을 제거함으로써 로그 연산들의 수를 줄여 준다. 구체적으로, 자신을 생성한 트랜잭션을 결코 벗어나지 못하는 개체들에 대한 복귀 로그 정보를 유지할 필요는 없다. 이것은 이러한 개체에 대한 복귀 로그 내의 정보가 트랜잭션이 중지되는 경우에만 사용되고, 이 시점에서 개체는 어차피 삭제될 것이기 때문이다.

본질적으로, 최적화는 트랜잭션의 개시 이래 할당된 개체들에 항상 속박되는 변수들을 식별한 후, 이들 개체에 대한 로그 연산들을 삭제한다. 따라서, 도 11은 새로 할당된 개체들에 대한 로그 연산들을 제거하기 위한 예시적인 프로세스(1100)의 흐름도를 나타낸다. 프로세스(1100)는 도 5의 블록 580에 대응한다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다.

프로세스는 블록 1110에서 시작되어, 컴파일러는 개체들의 트랜잭션에서 새로 할당된 개체들에 항상 속박되는 변수들을 식별한다. 다양한 구현에서, 블록 1110의 프로세스는 컴파일되고 있는 프로그램 내의 프로그램 포인트들의 상이한 세트들에서 변수들에 대한 정보를 수신하도록 수행된다. 따라서, 블록 1110의 분석은 특정 포인트, 작은 코드 범위에서, 또는 트랜잭션 내의 전체 변수 수명을 통해 참조들에 대한 정보를 학습하도록 수행될 수 있다.

이러한 분석 후, 블록 1120에서, 컴파일러는 이들 변수를 통해 연산하는 복귀 로그 연산들을 제거하고, 프로세스가 종료된다. 일 구현에서, 컴파일러는 힙 메모리에 액세스하는 STM 연산들을, 분해들이 로그 연산들을 포함하지 않는 연산들의 특수 확장 버전들로 대체함으로써 블록 1120의 프로세스를 수행한다. 다른 구현에서, 컴파일러는 분해된 로그 연산들을 명확히 제거하기 위해 STM 연산의 분해 후에 도 11의 프로세스를 수행한다.

블록 1110의 프로세스는 분석되고 있는 코드에 따라 간단하거나 복잡하다. 일례에서, 다음과 같은 코드는

p가 항상 아토믹 트랜잭션 블록 내의 새로 할당된 개체를 참조하는 것으로 공지됨을 의미한다. 따라서, p를 통해 작용하는 로그 연산들을 제거하는 것이 안전하다.

그러나, 다음과 같은 코드는

p가 항상 새로 할당된 개체들을 참조하는지에 대한 정보를 쉽게 제공하지 못한다. 따라서, 컴파일러는 변수들이 로그 제거에 적합한지의 여부를 식별하기 위해 분석을 수행해야 한다.

일 구현에서, 컴파일러는 각각의 변수가 새로 할당된 개체를 명확히 참조하고 있는 것으로 공지되는지를 지시하는 모든 프로그램 포인트에서 벡터를 사용하는 비트 벡터들을 사용한다. 이러한 구현은 로그 연산들이 제거될 수 있는 참조들을 올바르게 식별하지만, 일반적으로 느리고, 많은 메모리 사용을 필요로 한다. 다른 구현에서, 비트 벡터들은 기본 블록과 같은 큰 코드 섹션에 대한 요약 정보를 제공할 수 있다. 이러한 구현은 여전히 프로시저 간 분석에 대해 느릴 수 있다.

대안으로서, 일 구현에서, 컴파일러는 트랜잭션의 개시 이래 할당된 개체들에 항상 속박되는 변수들을 식별하기 위해 흐름 감지 프로시저 간 분석을 이용한다. 도 12는 예시적인 프로세스(1200)의 흐름도를 나타낸다. 프로세스(1200)는 도 11의 블록 1110에 대응한다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 도시된 구현에서, 프로세스(1200)는 트랜잭션 내의 각각의 기본 블록 상에서 수행된다.

도 12에 도시된 프로세스는 종속성 그래프를 동시에 구축하고 분석하기 위해 전체 프로그램의 각 함수 상에서 수행된다. 각각의 함수에 대해, 프로세스는 블록 1210에서 시작되어, 개체 유형 변수들에서 종속성 그래프 내의 격자 요소들 또는 노드들로의 맵핑이 생성된다. 맵은 블록 내의 임의 포인트에서 변수에 할당될 수 있는 값들의 종류를 나타낸다. 일 구현에서, 격자는 그 안에 3개의 요소, 즉 새로 할당되지 않을 수 있는 개체들을 참조하는 변수들을 나타내는 "Old", 새로 할당되어야 하는 개체들을 참조하는 변수들을 나타내는 "New", 및 정보가 존재하지 않는 변수들에 대한 "Unknown"을 갖는다. 블록 1220에서, 맵핑 내의 모든 값이 "Unknown"으로 설정된다. 이어서, 블록 1230에서, 컴파일러는 기본 블록을 통해 전진하여 블록 내의 제1 연산을 검사한다. 판정 블록 1235에서, 컴파일러는 그가 어떠한 연산 유형을 검사하고 있는지를 판정한다. 연산이 개체 할당인 경우, 블록 1240에서 컴파일러는 할당되고 있는 변수에 대한 맵핑에 "New"를 추가한다. 연산이 할당, 캐스트(cast) 또는 프로시저 호출인 경우, 블록 1250에서 컴파일러는 변수들 사이에 격자 값들을 전달한다. 따라서, 할당들 및 캐스트들은 그들의 추상 값을 할당된 변수에 전달한다. 호출들은 추상 값들을 호출 형식들(formals)로 그리고 반환 값으로부터 전달한다. 그러나, 연산이 위의 사례들과 다른 것인 경우, 블록 1260에서 격자는 연산이 할당되는 변수들에 대해 "Old"를 나타내도록 수정된다. 일 구현에서, 분석은 또한 새로 할당될 현재 트랜잭션의 커미트된 서브 트랜잭션 내에서 할당된 개체들을 고려한다.

이어서, 컴파일러는 지역 변수들에서 격자 값들 또는 그래프 노드들로의 맵핑을 위해 정보를 순방향으로 전달하고, 고정 포인트에 도달할 때까지 함수 내에서 반복한다. 따라서, 판정 블록 1265에서, 컴파일러는 if 문장의 끝과 같은 연결 포인트에 도달하였는지를 판정한다. 연결 포인트에 도달한 경우, 블록 1270에서 선행 블록들로부터의 격자 값들은 현재 블록에 대한 기존 맵과 포인트 와이즈(point-wise) 교차된다. 분석의 목적으로, 함수의 시작은 그의 호출 사이트들 모두로부터의 연결 포인트로 간주된다. 어느 경우에나, 프로세스는 판정 블록 1275로 진행하여, 검사할 연산들이 더 존재하는지를 판정한다. 그러한 경우, 프로세스는 판정 블록 1235에서 반복된다. 그렇지 않은 경우, 프로세스는 종료된다. 이러한 프로세스는 다른 함수들로부터의 변수들로의 그래프를 통한 전달을 유발할 수 있다. 프로세스가 트랜잭션 내의 모든 기본 블록 상에서 수행된 경우, "New"로 표시된 변수들은 이들의 로그 연산들이 제거될 수 있다. 종속성 추적은 다양한 구현에서 함수들이 상이한 순서로 처리될 수 있음을 의미한다. 이것은 또한, 함수의 새로운 호출자 또는 피호출자가 결정되는 경우 함수가 재차 분석될 필요가 없음을 의미한다.

3. 실행시간 최적화들의 예

본 장에서는 분해된 직접 액세스 STM의 구현이 설명된다. 개략적으로, 트랜잭션은 갱신들에 대해 엄격한 2 단계 로킹을 이용하며, 그가 판독하는 개체들에 대한 버전 번호들을 기록하여, 충돌 갱신들을 검출할 수 있다. 충돌 또는 데드록 시의 복구를 위해 롤백 로그가 사용된다. 하나의 최적화는 커미트 연산에 의해 사용되는 버전 번호들을 지원하기 위한 개체 포맷의 확장은 물론, 이러한 확장에 기초하여 개체에 대한 변경들을 결정하기 위한 빠른 기술을 필요로 한다. 트랜잭션 메모리의 로그들에 대한 엔트리들의 실행시간 필터링도 설명된다.

3.1 아토믹 커미트 연산들

개체 구조의 확장은 여기에 설명되는 STM 구현에서의 아토믹 커미트 연산과 관련하여 이해된다. 아토믹 커미트의 일례에서, DTMStart가 호출되고, 판독 및 갱신을 위해 개체들이 개방되고, 이러한 액세스를 아토믹하게 수행하려고 시도하기 위해 DTMCommit를 호출함으로써 커미트가 종결된다.

내부적으로, 커미트 연산은 판독을 위해 개방된 개체들을 검증하려고 시도함으로써 시작된다. 이것은 개체들이 개방된 이래 다른 트랜잭션들에 의해 개체들에 대해 어떠한 갱신도 이루어지지 않았음을 보장한다. 검증에 실패한 경우, 충돌이 검출되었으며, 따라서 트랜잭션의 갱신들이 롤백되고, 그가 갱신을 위해 개방한 개체들이 닫히며, 그 결과 개체들이 다른 트랜잭션들에 의해 개방될 수 있다. 검증에 성공한 경우, 트랜잭션은 충돌 없이 실행되었으며, 따라서 그가 갱신을 위해 개방한 개체들이 닫히고, 갱신들이 유지된다.

검증 프로세스는 DTMOpenForRead 커맨드의 호출에서 검증까지의 시간 범위 동안 트랜잭션이 판독한 개체들에 대한 어떠한 충돌 갱신도 존재하지 않았음을 검사한다. 갱신을 위해 개체들을 개방한 상태로 유지하는 것은 DTMOpenForUpdate 커맨드의 호출에서 STM 로그 내의 개체들의 닫힘까지의 시간 범위 동안 충돌을 방지한다. 결과적으로, 이러한 시간 범위들의 공통 부분 동안 개방된 임의의 개체에 대한 충돌 액세스는 존재하지 않으며, 트랜잭션은 검증이 시작되기 바로 전에 아토믹한 것으로 간주될 수 있다.

3.2 실행시간 환경

도 13은 실행시간 환경(1300)의 실행시간 동안 STM 성능을 최적화하도록 동작하는 개체들 및 소프트웨어 모듈들의 일례를 나타내는 블록도이다. 도 13은 특정 모듈들을 개별적으로 도시하고 있지만, 다양한 구현에서 모듈들은 병합되거나 다양한 조합으로 분할되거나, 도시되지 않은 다른 실행시간 소프트웨어 구조들의 일부로서 동작할 수 있다는 것을 알아야 한다. 도 13은 실행시간 환경에서 동작하는 개체(1310)를 팽창된 워드 헤더(1315)와 함께 도시하고 있다. 팽창된 워드 헤더를 갖는 개체의 동작은 다음 장에서 설명된다. 도 13은 또한 전술한 바와 같이 STM 구현의 검증 및 폐쇄 프로시저들을 구현하기 위한 판독 검증 모듈(1320) 및 개체 갱신 폐쇄 모듈(1330)을 도시한다. 실행시간 환경에서 개체들과 관련된 이들 모듈의 특정 양태들이 여기서 설명된다. 도 13은 또한 몇몇 실시예에서 불필요한 엔트리들을 필터링하여 이들이 복귀 로그(1360), 갱신 개체 로그(1370) 및 판독 개체 로그(1380)의 다양한 조합 내에 로깅되는 것을 방지하는 필터링 연관 테이블(1350)을 도시한다. 이러한 필터링 프로세스의 특정 구현들은 아래에 더 상세히 설명된다. 마지막으로, 도 13은 개체들이 더 이상 실행 프로그램에 도달할 수 없을 때 개체들의 할당을 해제하고 쓰레기 수집 동안 STM 로그들을 줄이는 기능을 하는 쓰레기 수집 모듈(1390)을 도시한다. 이러한 쓰레기 수집 모듈의 특정 구현은 아래에 설명된다.

3.3 개체 구조

본 장은 판독 전용 개체들의 검증 및 갱신되는 개체들 상의 개방 및 폐쇄 연산들을 지원하는 데 사용되는 구조들의 예를 설명한다. 일 구현에서, STM은 개체 상의 연산들의 목적으로 각 개체에 대해 2개의 추상 엔티티, 즉 어느 트랜잭션이 갱신을 위해 개체를 개방할지를 조정하는 데 사용되는 STM 워드, 및 트랜잭션이 판독한 개체들에 대한 충돌 갱신들을 검출하기 위해 고속 경로 코드에서 사용되는 STM 스냅샷을 사용한다. 이러한 데이터 구조들을 이용하는 연산들의 예는 다음과 같다.

개체의 STM 워드는 2개의 필드를 갖는다. 하나는 개체가 현재 임의의 트랜잭션에 의해 갱신을 위해 개방되는지의 여부를 지시하는 단일 비트이다. 그러한 경우, 워드의 나머지는 소유 트랜잭션(owning transaction)을 식별한다. 그렇지 않은 경우, 워드의 나머지는 버전 번호를 유지한다. OpenSTMWord는 (prev에서 next까지) STM 워드 상에서 아토믹 비교 및 스왑을 수행한다. CloseSTMWord는 워드를 지정 값으로 갱신한다.

도 14a 및 14b는 개체들 내에 STM 워드들을 구현하는 일례를 나타낸다. 도시된 구현은 Bartok 실행시간이 개체가 메모리 내에 표현될 때 각 개체에 단일의 다중 사용 헤더 워드를 연관시킨다는 사실을 이용하며, 이것을 이용하여 동기화 록들 및 해시 코드들(이들 중 어느 것도 여기서 설명되는 STM 기술들의 컴포넌트가 아니다)을 개체들과 연관시킨다. 도 14a 및 14b에서, 이러한 다중 사용 헤더 워드는 트랜잭션에서 갱신을 위해 개방된 적이 있는 개체들의 STM 워드를 유지하기 위해 추가 상태로 확장된다. 따라서, 도 14a에서, 개체(1400)는 다중 사용 헤더 워드(1410)를 포함하며, 이 워드는 그 안에 저장되는 값의 유형의 지시자(1413)를 포함하고, 이 지시자에는 실제 STM 워드(1418)가 이어진다. 지시자(1413)의 사용은 상이한 지시자 값들을 사용함으로써 다중 사용 워드가 해시 코드들 및 록들에 대해 사용되는 것을 허가한다. 일 구현에서, 개체에 대한 지시자(1413)가 록 또는 해시 코드가 워드 내에 저장되어 있음을 지시하는 경우, 아직까지는 개체에 대한 어떠한 STM 워드도 존재하지 않는 것으로 가정한다. 도 14a에 또한 도시된 바와 같이, STM 워드(1418)는 전술한 바와 같이 두 유형의 값들을 가질 수 있다. 예 1420에서, STM 워드는 개체(1400)가 갱신을 위해 개방되지 않은 것을 지시하는 비트를 포함하며, 따라서 워드의 나머지는 버전 번호를 유지한다. 예 1430에서, STM 워드는 개체가 갱신을 위해 개방된 것을 지시하는 비트를 포함하며, 따라서 STM 워드는 갱신을 위해 개체를 개방한 트랜잭션을 식별하였다.

다른 구현에서, 이러한 목적들 중 둘 이상을 위해(예를 들어, 해시 코드 및 STM 워드에 대해) 다중 사용 워드가 필요한 경우, 이것은 팽창되고, 외부 구조가 개체의 록 워드, 해시 코드 및 STM 워드를 유지한다. 따라서, 도 14b에서, 개체(1450)는 팽창된 헤더 워드를 사용하는 것으로 도시된다. 개체의 다중 사용 워드의 지시자(1465)는 헤더 워드가 팽창되었음을 지시하는 값을 포함하며, 다중 사용 워드의 나머지는 팽창된 헤더 워드 구조에 대한 메모리 어드레스를 포함한다. 따라서, 도 14b에서, 다중 사용 워드는 록 워드, 해시 코드 및 STM 워드를 포함하는 팽창된 헤더 워드 구조(1470)를 지시한다.

STM 워드와 달리, 개체의 STM 스냅샷은 개체의 트랜잭션 상태에 대한 힌트를 제공한다. 일 구현에서, 실행 시간 환경은 CloseSTMWord가 개체 상에서 호출될 때마다, 즉 스레드가 개체에 대한 갱신 액세스를 릴리스할 때마다 스냅샷이 변경되는 것을 보증한다. 이것은 충돌을 검출하기에 충분한 정보를 제공한다.

이러한 조건을 보증하는 하나의 방법은 개체의 다중 사용 워드의 값으로서 STM 스냅샷을 구현하는 것이다. 명백히, 이 구현은 STM 워드가 다중 사용 워드 내에 직접 저장될 때 스냅샷이 변경된다는 것을 의미한다. 그러나, 팽창된 헤더 워드가 사용될 때에는 반드시 변경되는 것은 아니다. 일 구현에서, 팽창된 헤더 워드들을 이용하는 개체들에 대한 스냅샷은 각각의 개체에 대한 팽창된 헤더 워드를 추적하고 조사할 수 있다. 그러나, 이것은 고속 스냅샷 명령들을 만드는 목표에 맞지 않는 비효율적인 실행이다. 따라서, 다른 구현에서는, 다중 사용 워드가 팽창된 경우, CloseSTMWord는 새로운 팽창된 구조를 생성하고, 그것에 이전 구조의 내용들을 복사한다. 이것은 STM 스냅샷이 고속으로 유지하면서 항상 개체의 다중 사용 워드의 값으로서 구현되는 것을 허가한다.

도 15a 및 15b는 그러한 CloseSTMWord의 구현의 결과들을 나타낸다. 도 15a에서, 개체(1500)는 CloseSTMWord의 실행 전에 도시된다. 개체(1500)는 팽창된 헤더 워드(1520)를 사용하며, 팽창된 헤더 워드(1520)의 어드레스를 그의 다중 사용 헤더 워드(1510)에 저장한다. 도 15b는 CloseSTMWord의 실행 후의 개체 및 실행시간 메모리에 대한 변경들을 도시한다. 실행 후, 새로운 팽창된 헤더 워드 데이터 구조(1540)가 생성되고, 다중 사용 헤더 워드(1510)에 저장된 어드레스가 변경되었다. 이것은 다중 사용 워드(1510)의 값을 포함하는 스냅샷이 폐쇄의 결과로서 변경되었음을 의미한다.

도 16은 개체 스냅샷들을 이용하여 검증을 수행하기 위한 예시적인 프로세스(1600)의 흐름도이다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 프로세스는 블록 1620에서 시작되어, 개체에 대한 스냅샷 데이터가 기록된다. 일 구현에서, 이러한 기록은 판독을 위해 개체가 개방될 때 수행된다. 이어서, 블록 1640에서, 판독 검증 모듈(1320)은 커미트 연산 동안 검증 시간에 개체에 대한 다른 스냅샷을 기록한다. 판정 블록 1660에서, 모듈은 2개의 모듈을 비교하여 이들이 동일한지를 파악한다. 이들이 일치하는 경우, 프로세스는 블록 1670으로 계속되어, 트랜잭션이 스냅샷이 고속 경로 테스트를 수행하도록 변경되지 않았다는 사실을 이용하는 커미트/중지 프로시저들을 계속하도록 허가된다. 스냅샷들이 일치하지 않는 경우, 블록 1680에서 판독 검증 모듈(1320)은 트랜잭션이 커미트 또는 중지할 수 있는지를 판정하기 위해 일치하는 스냅샷들의 존재를 이용할 수 없는 커미트/중지 프로시저들을 수행하고, 프로세스는 종료된다. 일 구현에서, 이러한 2개의 상이한 세트의 프로시저들은 고속 경로 및 저속 경로 프로시저들로서 공지된다.

블록 1670 및 블록 1680의 프로세스들 간의 중요한 차이는, 블록 1670의 프로세스가 스냅샷이 변경되지 않았다는 것을 앎으로써 불필요한 테스트 또는 메모리 액세스를 피할 수 있고, 따라서 블록 1680의 테스트보다 빠르게 실행할 수 있다는 점이다. 다양한 구현에서, 이러한 테스트들의 정확한 특성은 기반 트랜잭션 메모리 구현의 특성에 의존할 수 있다. 예를 들어, 코드 예 6에서 후술하는 일 구현에서, 2개의 스냅샷이 일치하는 경우에 검증을 수행하는 코드는 단일 STM 워드를 검사하여 이것이 트랜잭션에 의해 소유되는지, 그리고 그 트랜잭션이 현재 검증하고 있는 것과 동일한지를 판정하기만 하면 된다. 이와 달리, 이 예에서 스냅삿들이 일치하지 않는 경우, 다른 STM 워드는 물론, 소정 환경에서의 갱신 엔트리가 탐색되어야 한다. 이러한 추가적인 메모리 액세스들은 물론, 이들에 대해 수행되는 추가적인 비교들은 이러한 블록 1680의 구현이 일반적으로 블록 1670의 대응 구현보다 느리다는 것을 의미한다.

도 17은 팽창된 헤더 워드를 이용하여 개체를 수정하기 위한 예시적인 프로세스(1700)의 흐름도이다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 프로세스는 블록 1720에서 시작되어, 개체가 수정된다. 일 구현에서, 이것은 STM 갱신 명령 때문일 수 있다. 다른 구현에서, 개체의 팽창된 헤더 워드 자체가 록 워드 또는 해시 코드에서 수정될 수 있다. 이어서, 블록 1740에서, 개체 갱신 폐쇄 모듈(1330)은 폐쇄 명령에 응답하여 새로운 팽창된 헤더 워드를 생성한다. 프로세스는 블록 1760으로 계속되어, 모듈은 정보를 이전 헤더 워드에서 새로운 헤더 워드로 복사한다. 이어서, 블록 1780에서, 개체 갱신 폐쇄 모듈(1330)은 새로운 팽창된 헤더 워드를 지시하도록 개체의 다중 사용 헤더 워드를 수정한다.

마지막으로, 블록 1790에서, 쓰레기 수집이 발생하고 있는 경우, 쓰레기 수집기(1390)에 의한 재생시까지 이전 팽창된 헤더 워드가 그대로 남겨진다. 개체 갱신 폐쇄 모듈은 이를 행함으로써, 상이한 스레드에서 개체에 대한 제2 변경이 이루어지고, 제1 팽창된 헤더 워드로부터 재생된 메모리에 제3 팽창된 헤더 워드가 기입되는 시나리오를 방지한다. 개체를 판독하는 트랜잭션이 개방된 동안 이것이 발생하는 경우, 개체에 대한 스냅샷은 두 번 변경된 경우에도 커미트 시간에 변경되지 않은 것으로 보일 수 있다. 이것은 판독을 행하는 트랜잭션이 개체 상의 두 번의 수정으로 인해 중단되어야 할 때 커미트되는 것을 허가할 수 있다. 일 구현에서, 블록 1790의 프로세스는 개체를 재생하는 것이 안전한 시간까지 개체를 그대로 남김으로써 수행되는데, 일례에서 이것은 어떠한 트랜잭션도 판독을 위해 개체를 개방하지 않을 때 행해진다.

4. STM 로깅 및 커미트의 예

4.1 SMT 로그 구조의 예

각각의 스레드는 3개의 로그를 갖는 개별 트랜잭션 관리자를 구비한다. 판독 개체 로그 및 갱신 개체 로그는 트랜잭션이 판독을 위해 또는 갱신을 위해 개방한 개체들을 추적한다. 복귀 로그는 중지시 복귀되어야 하는 갱신들을 추적한다. 모든 로그는 순차적으로 기입되며 결코 검색되지 않는다. 개별 로그들은 그들 내의 엔트리들이 상이한 포맷들을 갖기 때문에, 그리고 커미트 동안 시스템이 상이한 종류의 엔트리들에 대해 차례로 반복하여야 하기 때문에 사용된다. 각각의 로그는 엔트리들의 어레이들의 리스트 내로 편성되며, 따라서 이들은 복사 없이 증가할 수 있다.

도 18a, 18b 및 19a-c는 예 2a로부터의 리스트 예를 이용하는 로그들의 구조를 나타낸다. 도 18a는 10의 값을 갖는 단일 노드를 유지하는 리스트의 초기 상태를 나타낸다. 개체들에 대한 다중 사용 워드들은 STM 워드들을 유지하기 위해 사용되고 있는 것으로 가정하며, 이 경우에 개체들은 버전 90 및 100이다. 도 18a, 18b 및 19a-c의 도시된 예에서, STM 워드의 우측 상의 두 자리 숫자 값들은 도 14a, 14b, 15a 및 15b의 지시자들에 대응한다.

예 3으로부터의 하나의 연산은 버전 번호를 갱신 개체 로그 내의 새로운 엔트리에 대한 포인터로 아토믹하게 대체하기 위해 OpenSTMWord를 이용하여 갱신을 위해 this를 개방한다. 의사 코드의 일례가 예 4로서 이어진다.

도 18b는 이 결과를 나타낸다. 도시된 구현에서, "로그 청크 내의 오프셋" 필드는 (도 18b의 List 노드로부터의 로그와 같은) 로그로의 내부 포인트를 그것을 유지하는 로그 엔트리들의 어레이에 대한 참조로 맵핑하는 빠른 방법으로서 쓰레기수집 동안 사용된다.

리스트 합산 예는 판독을 위해 각각의 리스트 노드를 개방하도록 진행한다. DTM은 이것을 간단하게 하는데, 즉 각각의 개체에 대해 개체 참조 및 그의 현재 STM 스냅샷이 로깅된다. 예 5는 의사 코드에서 이것의 예를 보여준다.

도 19a는 이것이 생성하는 로그 엔트리를 나타낸다. 충돌을 검출하기 위한 어떠한 시도도 없고, 충돌이 드물다는 설계 가정이 이어지며, 따라서 이를 일찍 발견하는 이익들은 검사의 비용만 못하다.

리스트 노드들을 판독한 후, 최종 단계는 Sum 필드를 갱신하는 것이다. DTMLogFieldStore는 도 19b에 도시된 바와 같이 복귀 로그 내의 엔트리에 겹쳐쓰인 값을 기록한다. 이것에 대한 의사 코드는 생략되며, 사용되는 특정 레코드는 일 구현에서 사용되는 Bartok 시스템에서의 쓰레기 수집 지원에 의해 영향을 받고, 다른 설계들은 다른 시스템들에 적합할 것이다. 복귀 로그 엔트리는 겹쳐쓰인 값의 어드레스를 (개체, 오프셋) 쌍으로서 기록한다. 이것은 몇몇 쓰레기 수집기에서 고비용으로 처리되는 내부 포인터들의 이용을 피한다. 엔트리는 또한 스칼라 또는 참조 유형 스토어들을 구별한다. 이 유형 정보는 몇몇 쓰레기 수집기에서 필요하다. 마지막으로, 엔트리는 겹쳐 쓰인 값을 기록한다. 다른 구현에서, 쓰레기 수집 동안 보다 많은 작업의 비용으로, 어드레스 및 겹쳐 쓰인 워드만을 유지하는 보다 짧은 2 워드 로그 엔트리가 사용될 수 있다.

4.2 커미트 프로시저들의 예

여기에 설명되는 구현들에서는 DTMCommit에 대해 2개의 단계가 존재하는데, 즉 제1 단계는 판독을 위해 개방된 개체들에 대한 충돌 갱신들을 검사하고, 제2 단계는 갱신을 위해 개방된 개체들을 닫는다. 판독을 위해 개방된 개체들은 명시적으로 닫을 필요가 없는데, 이는 그 사실이 스레드 전용 트랜잭션 로드들에만 기록되기 때문이다.

아래의 예 6은 ValidateReadObject의 구조를 나타낸다. 의사 코드에서 다수의 사례가 존재하지만, 전반적인 설계는 DTM 인터페이스 상에서의 연산들과 관련하여 사례들의 분리(disjunction)로서 간주되는 경우 보다 명백하다. 아래의 사례들 V1, V2 및 V3는 충돌이 발생하지 않았음을 지시한다.

- V1 - 개체는 트랜잭션의 지속 기간 내의 임의의 포인트에서 갱신을 위해 개방되지 않았다.

- V2 - 개체는 전체 지속 기간 동안 현재 트랜잭션에 의해 갱신을 위해 개방되었다.

- V3 - 개체는 최초에 갱신을 위해 개방되지 않았으며, 현재의 트랜잭션이 갱신을 위해 개체를 개방하는 다음 트랜잭션이었다.

- V4 - 개체는 전체 지속 기간 동안 다른 트랜잭션에 의해 갱신을 위해 개방되었다.

- V5 - 개체는 최초에 갱신을 위해 개방되지 않았으며, 다른 트랜잭션이 갱신을 위해 개체를 개방하는 다음 트랜잭션이었다.

이들 사례는 예시적인 의사 코드 내에 표시된다. 몇몇은 다수의 시간에 발생하는데, 이는 실제 충돌로 인해 STM 스냅샷에 대해 행해지는 테스트가 실패하는 경우와 충돌 없이(예를 들어, 개체의 다중 사용 워드가 팽창될 때 STM 스냅샷이 변경되기 때문에) 테스트가 실패하는 경우를 구별하는 것이 유용하기 때문이다.

예 7은 갱신을 위해 개방된 개체를 닫는 데 사용되는 CloseUpdatedObject 연산을 나타낸다.

도 19c는 리스트 개체의 헤더 내에 새로운 버전 번호 91이 배치된 리스트 구조에 대한 결과적인 갱신을 나타낸다.

버전 버전에 이용할 수 있는 29 비트에 의해 약 500M 개의 상이한 버전을 얻을 수 있음을 알 수 있다. 도시된 설계는 실행되는 트랜잭션이 판독을 위해 개체를 개방하는 동안 버전 번호가 동일 개체에서 재사용되지 않는 한은 버전 번호들이 오버플로우되는 것을 보증하는데, A-B-A 문제는 판독 트랜잭션이 번호에 대한 약 500M 개의 갱신이 있을 수 있다는 것을 검출하지 않고도 성공적으로 커미트되는 것을 가능하게 한다.

정확성을 위해, 일 구현에서, 이것은 (a) 500M 개의 트랜잭션마다 적어도 한 번 쓰레기 수집을 행하고, (b) 쓰레기 수집시마다 실행 트랜잭션들을 검증함으로써 방지된다. 판독 개체 로그 내의 엔트리는 로깅된 버전 번호가 현재 번호와 일치하는 경우에만 유효하며, 그 결과는 각각의 개체를 방문하여 그의 버전 번호를 갱신할 필요 없이 각각의 쓰레기 수집이 500M개의 트랜잭션의 '클럭을 리셋'하는 것이다.

5. 실행시간 로그 필터링

본 장은 확률적 해싱 스킴을 이용하여 판독 개체 로그 및 복귀 로그로부터 사본들을 필터링함으로써 사본들을 필터링하는 실행시간 기술을 설명한다. 로그 필터링은 일반적으로, a) 로그가 상당한 공간을 차지하여 시스템 자원을 고갈시킬 수 있고, b) 특정 메모리 위치가 기입 또는 판독된 것으로서 로깅된 경우 더 이상 로깅할 필요가 없기 때문에 유용하다. 이것은, 검증 동안 판독 개체 로그로부터 필요한 유일한 정보는 트랜잭션 전의 개체의 STM 스냅샷이고, 복귀 로그로부터 필요한 유일한 정보는 트랜잭션 전의 갱신된 메모리 위치들의 값이기 때문이다. 이것은 트랜잭션 내에서 변경되지 않으므로, 트랜잭션마다 주어진 메모리 위치에 대해 하나의 로그 엔트리만이 필요하다.

제4장의 구현에서는, 갱신 개체 로그 내의 엔트리들을 필터링하는 것은 필요하지 않다. 이것은 DTMOpenForUpdate가 동일 트랜잭션 내에서 동일 갱신 개체 헤더에 대해 복제 로그 엔트리들이 생성되는 것을 허가하지 않을 것이기 때문이다. 다른 구현들에서, 이러한 사본들은 생성될 수 있고, 따라서 필터링될 수 있다.

일반적으로, 필터는 두 가지 연산을 지원한다. 제1 연산 "필터"는 지정된 워드가 필터 내에 존재해야 하는 경우에 참을 반환한다. 이것은 지정된 워드가 필터 내에 존재하지 않을 수 있는 경우에는 거짓을 반환하고, 그러한 때에 필터에 워드를 추가한다. 따라서, 이러한 필터는 검색시 거짓 부정(false negative)을 허용하는 확률 세트로서 작용한다(즉, 이러한 필터는 워드들이 실제로 존재할 때 워드들이 필터 내에 존재하지 않는다고 주장할 수 있지만, 워드가 실제로 존재하지 않을 때에는 워드가 필터 내에 있다고 주장하지 못한다). 제2 연산 "소거"는 필터 내의 모든 워드를 제거한다.

소프트웨어 트랜잭션 메모리(STM)와 관련하여, 필터는 STM이 유지하는 트랜잭션 로그들 중 하나에 동일 워드의 내용들이 기입되는 횟수를 줄이는 데 사용될 수 있다.

5.2 해시 테이블 필터링의 예

여기에 설명되는 필터링 스킴은 연관 테이블을 이용하여 판독 개체 로그 및 복귀 로그에 대한 복제 로깅 요청들을 확률적으로 검출한다. 여기에 설명되는 구현들은 해시 테이블과 관련되지만, 대안 구현들에서 필터링 기술들 및 시스템들은 연관 테이블의 상이한 구현들을 이용할 수 있다는 것을 인식할 것이다. 하나의 구현은 어드레스의 해시를 그 해시를 갖는 어드레스들과 관련된 가장 최근의 로깅 연산의 상세에 맵핑하는 스레드 단위 테이블들을 사용한다.

일 구현에서, 판독 개체 로그 및 복귀 로그 양자를 필터링하기 위해 하나의 연관 테이블만이 필요하다는 점에 유의할 수 있다. 판독 개체 로그에 대한 스토어들은 개체의 헤더 워드의 어드레스를 사용하는 반면, 복귀 로그에 대한 스토어들은 로깅되고 있는 워드의 어드레스를 사용한다. 이러한 어드레스 세트들은 분리되므로, 단일 테이블은 판독 개체 및 갱신 액세스들 간의 충돌을 나타내지 않으며, 따라서 양 로그에 대해 사용될 수 있다.

도 20은 테이블의 설계를 나타낸다. 도 20은 해시 테이블(2000)로서 구현되는 연관 테이블을 나타낸다. 도 20에 도시된 바와 같이, 해시 테이블(2000) 내의 각각의 엔트리는 메모리 어드레스(2020) 및 트랜잭션 번호(2030)를 포함한다. 엔트리들은 일련의 슬롯 번호들(2010)에 의해 편성된다.

일 구현에서, 어드레스를 해시 인덱스 및 태그로 분할함으로써 특정 메모리 어드레스에 대한 슬롯 번호를 식별하는 해시 코드에 도달한다. 따라서, 이러한 구현에서, 해시 함수는 단순히 워드 W로부터 최하위 비트들의 일부를 사용하여 테이블에서 사용할 슬롯 S를 선택한다. 따라서, 워드 W 내의 비트들은 2개의 부분으로 분할되는 것으로 간주될 수 있는데, 최하위 비트들은 사용할 슬롯을 식별하는 것을 돕는 해시 코드이고, 나머지는 어드레스를 고유하게 식별하는 태그로서 기능한다. 예를 들어, 워드 0x1000은 태그-1 슬롯-0을 갖고, 워드 0x1001은 태그-1 슬롯-1을 갖고, 워드 0x2000은 태그-2 슬롯-0을 갖고, 워드 0x2001은 태그2- 슬롯-1을 갖는 등등일 것이다. 대안 구현들에서는 상이한 해싱 스킴들이 이용된다.

또한, 해시 테이블(2000)은 트랜잭션 번호를 메모리 어드레스와 별개로 나타내지만, 다양한 구현에서 트랜잭션 번호는 XOR 연산의 사용에서와 같이 메모리 어드레스와 조합된다. XOR 연산은 일 구현에서 비교적 빠른 연산이고 계속되는 XOR에 의해 복귀될 수 있으므로 사용된다. 대안 구현들에서, 메모리 어드레스 내의 낮은 순위 비트들을 트랜잭션 번호로 대체하거나 XOR 연산이 아니라 덧셈 연산을 사용하는 것과 같이 트랜잭션 번호를 기록하는 상이한 방법들이 이용된다. 이들은 동일 해시 코드로 해시되는 2개의 어드레스(a₁, a₂) 및 2개의 트랜잭션 번호(t_{1 ,} t₂)에 대해 a₁=a₂ 및 t₁=_t2일 때만 op(a₁, t₁)이 op(a_2, t₂)와 동일한 특성을 각각 공유한다는 점에서 유용하다. 이러한 특성은 삽입된 조합 값들이 이들이 생성된 특정 어드레스 및 트랜잭션 번호에 고유하다는 신뢰를 제공한다.

스레드 지역적인 트랜잭션 번호의 사용은 선행 트랜잭션에 의해 기록된 엔트리가 현재 트랜잭션과 관련된 엔트리와 혼동되는 것을 방지한다. 트랜잭션 번호의 식별은 트랜잭션 번호들의 시퀀스에 사용된 비트들이 오버플로우할 때만 테이블이 소거되는 것을 허가한다. 일 구현에서, 테이블은 트랜잭션 번호들의 시퀀스가 오버플로우할 때마다 한 번씩 소거되는데, 이는 상이한 트랜잭션들로부터 생성된 2개의 엔트리가 동일 트랜잭션 번호를 사용하는 것을 방지함으로써 테이블 내의 충돌을 피한다. 다른 구현에서, 테이블 내의 하나의 슬롯이 트랜잭션마다 소거되는데, 몇몇 구현에서는, 트랜잭션마다 작은 오버헤드를 추가하는 것이 이따금씩 큰 오버헤드를 추가하는 것보다 바람직할 수 있다. 다른 구현들에서는 한꺼번에 모든 테이블 소거를 수행하는 것이 바람직하다.

도 21은 로그 엔트리들을 필터링하기 위한 예시적인 프로세스(2100)의 흐름도이다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 프로세스는 블록 2110에서 시작되어, 현재 트랜잭션의 시작에서 트랜잭션 카운트가 갱신된다. 이 카운트는 해시 테이블에서 사용되는 트랜잭션 번호를 제공한다. 이어서, 판정 블록 2115에서, 트랜잭션 카운트 한계에 도달하였는지를 판정한다. 일 구현에서, 이 한계는 카운트에 할당된 비트들의 수를 오버플로우함으로써 결정된다. 다른 구현에서, 한계는 메모리 제한들에 기초하거나, 해시 테이블의 성능을 미세 조정하도록 선택될 수 있다. 한계에 도달하지 않은 경우, 블록 2140에서 로깅될 어드레스가 해시 테이블을 통해 필터링된다. 이와 달리 한계에 도달한 경우, 블록 2120에서 카운트가 리셋되고, 블록 2130에서 테이블이 소거된다. 이어서, 블록 2140에서 로깅될 어드레스가 해시 테이블을 통해 필터링된다.

도 22는 로그 엔트리들을 필터링하기 위한 예시적인 프로세스(2200)의 흐름도이다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 다양한 구현에서, 프로세스(2200)는 프로세스(2100)의 블록 2140의 프로세스에 대응한다. 프로세스(2200)는 블록 2210에서 시작되어, 적절한 해시 테이블 엔트리를 발견하기 위해 어드레스가 해시된다. 이어서, 블록 2220에서, 필터링될 어드레스가 (트랜잭션 카운트로부터 수신된) 현재 트랜잭션 번호와 XOR된다. 일 구현에서, 해싱은 전술한 바와 같이 어드레스를 해시 코드 및 태그 값으로 분할함으로써 수행된다.

이어서, 프로세스는 판정 블록 2225로 진행하여, 해시 엔트리의 값이 XOR 결과에 대해 검사된다. 둘이 일치하는 경우, 메모리 액세스를 다시 로깅할 필요가 없으며, 블록 2230에서 로그는 기입되지 않는다. 그러나, 둘이 일치하지 않는 경우, 블록 2240에서 XOR 결과가 해시 테이블 엔트리에 기입되고, 블록 2250에서 엔트리가 로그에 기입된다.

5.3 새로 할당된 개체들에 대한 실행시간 로그 필터링

일 구현에서, 여기에 설명되는 STM 시스템 및 기술들은 현재 트랜잭션에 의해 할당된 개체들을 식별하여 이들에 대한 임의의 복귀 로그 엔트리들의 기입을 피한다. 이것은 전술한 정적 컴파일-시간 분석이 새로 할당된 개체들에 대한 특정 로그 연산들을 누락하거나 제거할 수 없는 경우에 백업을 제공한다. 이러한 실행시간 기술은 현재 트랜잭션이 중지되는 경우에 개체들이 폐기되기 때문에 안전하다. 일 구현에서, 이것은 새로 할당된 개체들 상에서 작동하도록 특수화되는 DTMOpenForUpdate의 버전을 이용하여, 그리고 개체가 트랜잭션 할당된 것으로 표시하기 위하여 이러한 연산이 지정된 STM 워드 값을 기입하게 함으로써 수행된다.

6. 쓰레기 수집의 예

일반적으로, 쓰레기 수집("GC")은 메모리 개체가 프로그램 내의 어떠한 스레드에 의해서도 더 이상 필요하지 않으므로 메모리 개체가 언제 안전하게 할당 해제될 수 있는지를 자동으로 결정하기 위한 메커니즘을 제공한다. 쓰레기 수집은 많은 최신 프로그래밍 언어에 포함되며, Microsoft.NET 프레임워크의 일부를 구성한다.

본 장은 GC를 전술한 STM 기술들에 통합하는 다양한 구현을 설명한다. 그러나, 이러한 통합은 쉽지 않다. 문제를 설명하기 위하여, 다음 예를 고려한다.

예시의 목적으로, E1 및 E2에서 수행되는 계산들 양자가 충분히 복잡하여 메모리의 고갈 없이 이들을 완료하기 위해 GC가 필요한 것으로 가정한다. 또한, t1에 속박된 LargeTemporaryObject는 E1에서만 사용되고, 마찬가지로 t2에 속박된 LargeTemporaryObject는 E2에서만 사용되는 것으로 가정한다. '아토믹' 블록 없이 실행되는 경우, t1에 의해 점유되는 공간은 E1이 종료된 경우에 재생될 수 있다.

이러한 예는 기존 트랜잭션 메모리 시스템들 및 GC들과 관련해서는 실시될 수 없다. 이러한 시스템들에서는 다음 두 가지 문제 중 하나가 발생한다.

1. 몇몇 비 TM 인식 GC는 GC가 발생할 때 모든 메모리 트랜잭션이 중지될 것을 강요한다. 이러한 시스템들 상에서 E1 및 E2와 같은 계산들은 아토믹 블록에서 실행될 수 없다.

2. 다른 비 TM 인식 GC들은 개체들이 본 발명의 TM 인식 GC에서보다 길게 유지될 것을 강요한다. 이러한 시스템들 상에서, 상기 예는 성공적으로 실시될 수 있지만, t1이 후에 불필요해지는 것으로 알려진 E2 동안에 GC가 발생하는 경우에도 t1 및 t2가 아토믹 블록의 정말 끝까지 유지될 것이다.

일 구현에서, 이러한 문제들은 (a) 스레드들이 아토믹 블록들을 실행하고 있는 중에 GC가 발생하는 것을 허가하고, (b) 아토믹 블록이 성공적으로 완료되는지 또는 재실행되는지에 관계없이 GC가 프로그램에 의해 불필요한 것으로 보증될 수 있는 개체들을 복구하는 것을 허가하는 TM 인식 GC에 의해 해결된다.

다양한 구현에서, 쓰레기 수집 기술들은 현재 아토믹 블록 내에 할당된 개체들을 식별하기 위해 아토믹 트랜잭션 블록들의 구현에 사용하기 위한 기술들을 포함한다. 구현들은 또한 STM의 데이터 구조에 의해 참조되는 어떠한 개체들이 프로그램에 의해 불필요한 것으로 보증되는지를 식별하기 위한 기술들을 포함한다. 마지막으로, GC 구현들은 TM의 데이터 구조 내의 어떤 엔트리들이 프로그램의 추가 실행에 필요하지 않은지를 식별하기 위한 기술들을 포함한다.

아래의 설명은 전술한 시스템에 특히 의존하지만, 여기에 설명되는 구현들은 이러한 설정으로 제한되지 않으며, 아마도 하드웨어 트랜잭션 메모리를 포함하는 다른 형태의 트랜잭션 메모리와 관련하여 이용될 수 있다.

여기서 설명되는 구현들은 전체 정지(stop-the-world) 추적 쓰레기 수집기, 예를 들어 마크-스위프 쓰레기 수집기 또는 복사 쓰레기 수집기와 관련하여 설명된다. 그러나, 이것은 개시의 간략화를 위한 것이며, 구현들은 이러한 설정으로 제한되지 않고, STM을 세대별 쓰레기 수집, 동시 쓰레기 수집 또는 병렬 쓰레기 수집과 같은 다른 쓰레기 수집 기술들과 통합하기 위해 공지된 접근법들이 이용될 수 있다. 일 구현에서, STM은 세대별 쓰레기 수집과 통합된다.

고 레벨에서, 전체 정지 추적 GC의 연산은 다음 프로시저로서 요약될 수 있다. 먼저, 애플리케이션 내의 모든 애플리케이션 스레드(때때로 "반환자 스레드"로 공지됨)를 중지시킨다. 이어서, 반환자 스레드들이 최초로 개체들에 액세스한 "루트들" 각각을 방문하여, 이들 루트로부터 참조되는 개체들이 수집 후에 유지됨을 보증한다. (루트들은 프로세서의 실행 반환자 스레드들의 저장된 레지스터 내용들, 스레드들의 스택들 상의 개체 참조들 및 프로그램의 정적 필드들을 통해 이들 스레드에 보이는 개체 참조들을 포함한다.) 이렇게 유지되는 개체들은 종종 "그레이"로 지칭되며, 개체들의 나머지는 초기에 "화이트"로 지칭된다. 이어서, 각각의 그레이 개체에 대해, 그가 포함하는 개체 참조들을 방문한다. 이들 참조가 식별하는 임의의 화이트 개체들은 또한 그레이로 표시되며, 그레이 개체 내의 모든 참조가 방문된 경우, 개체는 블랙으로 표시된다. 더 이상 그레이 개체가 존재하지 않을 때까지 이 단계를 반복한다. 유지되는 임의의 화이트 개체들은 쓰레기로서 간주되며, 이들이 차지하는 공간은 재할당을 위해 반환자 스레드들이 이용할 수 있게 될 수 있다. 마지막으로, 반환자 스레드들을 다시 시작한다. 아래의 예에서, 그레이 개체들은 "방문된" 개체들로서 지칭되며, 공지된 화이트 개체들은 "도달 불가능"하다.

STM과 GC를 통합하는 일 구현에서, 모든 트랜잭션은 GC를 개시할 때 중지된다. 이것은 분명한 단점을 갖는다. 다른 구현에서, GC는 STM의 데이터 구조들을 반환자 스레드들의 루트들의 일부로서 간주하며, 따라서 로그들 내의 엔트리들에 의해 참조되는 것들에 기초하여 개체들을 방문한다. 이러한 구현에서, 몇몇 로그들로부터의 개체들에 대한 참조들은 이들을 통해 도달 가능한 메모리를 유지할 것을 GC에게 요구하는 "강한 참조들"로서 간주된다.

이러한 구현은 STM 시스템과 GC 간의 소정의 통합도를 허가하지만, 다른 구현에서는 보다 높은 통합도가 존재한다. 도 23은 STM 시스템에서 쓰레기 수집을 수행하기 위한 쓰레기 수집 모듈(1390)에 의해 수행되는 예시적인 프로세스(2300)의 흐름도이다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 아래에 설명되는 프로시저들에서, GC는 개체들 및 로그 엔트리들을 더 이상 사용할 수 없을 때 이들을 할당 해제하고 중복 엔트리들을 제거함으로써 로그들을 줄이기 위해 STM의 특수 지식을 이용할 수 있다. 일 구현에서, 도 23의 프로세스는 방문된 개체의 개체 참조들의 각각을 방문하는 위의 전형적인 GC 프로시저에서의 단계를 대신하여 수행된다. 대안 구현들에서, 도 23의 프로세스는 다른 범용 GC 프로시저들 내로 통합될 수 있다.

몇몇 구현에서, 도 23의 프로세스는 STM 시스템 내의 로그들 상의 2개의 품질을 인식한다. 첫 번째는 현재 트랜잭션이 액세스를 시도한 개체들을 식별하는 로그들이다. 다양한 구현에서 이러한 종류의 로그들은 PLDI 논문에 설명된 구현들에서 판독 개체들, 갱신 개체들 및 복귀 로그들 내에서 액세스되는 개체들에 대한 참조들을 포함한다. 하나의 용어법에서, 이러한 로그들로부터의 개체들에 대한 몇몇 참조들은 "약한 참조들"로 간주되는데, 이것은 GC가 이러한 약한 참조들을 제외하고는 도달할 수 없는 개체들에 의해 사용되는 메모리를 재생할 것이라는 것을 의미한다. 이러한 프로세스를 수행함에 있어서 GC에 의해 인식되는 또 하나의 품질은 트랜잭션의 커미트시 또는 중지시에 메모리로 복원되는 개체 참조들을 식별하는 로그들이다. 이러한 종류의 로그들은 복귀 로그들 내의 이전 값들을 포함한다. 이러한 로그들로부터의 참조들은 소정의 용어법에서 "강한 참조들"로서 지칭된다. 전술한 바와 같이, "강한 참조들"은 이들을 통해 도달 가능한 메모리를 유지할 것을 GC에게 요구한다.

프로세스는 블록 2310에서 시작되어, GC 모듈(1390)이 복귀 로그들(1360) 내의 각각의 엔트리의 "이전 값" 필드에 의해 참조되는 개체들을 방문하며, 따라서 이들 개체가 도달 불가능한 것으로 간주되는 것을 방지하고, 현재 트랜잭션이 중지되는 경우에 이들의 재생을 방지한다. 이어서, 블록 2320에서, 로그들로부터 소정의 특수 사례 엔트리들이 제거된다. 이러한 제거 프로세스의 일례는 도 24와 관련하여 아래에 상세히 설명된다.

프로세스는 블록 2325로 계속되어, GC 모듈이 모든 도달 가능 개체를 방문하여 도달 불가능한 개체들의 최종 세트에 도달하기 위하여 이미 방문된 각각의 개체가 포함하는 개체 참조들을 방문한다. 이어서, 블록 2330에서, GC 모듈은 도달 불가능한 개체들을 참조하는 판독 개체 로그(1380) 내의 엔트리들을 검토한다. 판정 블록 2335에서, GC 모듈은 각각의 엔트리에 대해 엔트리에 의해 참조되는 개체들에 대한 충돌하는 동시 액세스가 존재하는지를 판정한다. 일 구현에서, GC는 각각의 엔트리에 대해 엔트리 내의 버전 번호가 개체의 버전 번호와 일치하는지를 판정함으로써 이를 행한다. 그러한 경우, 엔트리는 현재이고 개체는 도달 불가능하므로, 블록 2350에서 엔트리는 단순히 로그로부터 할당 해제된다. 그러나, 버전 번호들이 일치하지 않는 경우, 현재 트랜잭션은 유효하지 않다. 이 시점에서, 블록 2340에서 GC 모듈 자체는 트랜잭션을 중지하고, 트랜잭션에 대한 모든 로그 엔트리를 삭제한다. 대안 구현에서, 블록들 2335, 2340 및 2350의 특정 검사들 및 프로세스들이 생략될 수 있고, 공지된 도달 불가능한 개체들에 대한 엔트리들이 검토 없이 판독 개체 로그로부터 할당 해제될 수 있으며, 트랜잭션을 중지할 지의 여부를 판정하기 위하여 STM의 다른 실행시간 시스템들에 의존할 수 있다.

이어서, 블록 2360에서, GC 모듈은 갱신 개체 로그(1370) 내의 엔트리들을 검토하고, 도달 불가능한 개체들을 참조하는 모든 엔트리를 할당 해제한다. 이어서, 블록 2370에서, 복귀 로그(1360) 내의 엔트리들에 대해 동일 프로세스가 수행된다. 마지막으로, 블록 2380에서, GC 모듈은 모든 도달 불가능한 나머지 개체를 할당 해제하도록 진행한다.

확장 구현들은 특수 사례들을 이용하여 STM 로그들로부터 추가 엔트리들을 제거한다. 도 24는 특수 사례 로그 엔트리들을 제거하기 위한 쓰레기 수집 모듈(1390)에 의해 수행되는 예시적인 프로세스(2400)를 나타내는 흐름도이다. 도 24의 프로세스는 도 23의 블록 2320에 대응한다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 여기에서의 설명은 이들 확장을 프로세스 2400 및 블록 2320의 프로세스들의 일부인 연속 단계들로서 기술하지만, 소정 환경들에서 도 24의 프로세스들은 서로 독립적으로, 그리고 몇몇 사례에서는 기본 구현으로부터 독립적으로(예를 들어, GC가 아닌 시간들에서 로그들을 줄이기 위해) 사용될 수 있으며, 로그들 내의 엔트리들이 방문되어야 하는 횟수를 줄이기 위해 빠른 구현이 이들 단계 중 하나 이상의 부분들을 조합할 수 있다는 것을 인식할 것이다.

프로세스(2400)는 블록 2410에서 시작되어, 하나의 트랜잭션만이 활성인 경우, GC 모듈(1390)은 도달 불가능한 개체들을 참조하는 복귀 로그(1360)로부터의 엔트리들을 즉시 롤백하고 제거한다. 블록 2420에서, GC 모듈은 판독 개체 로그(1380) 및 복귀 로그(1360)를 검토하고, 엔트리들이 현재 트랜잭션 블록 내에서 생성된 도달 불가능한 개체들을 참조하는 경우에 이들 로그로부터 엔트리들을 제거한다. 개체가 트랜잭션이 시작된 후에 할당되어 현재 도달 불가능한 경우에는 트랜잭션이 커미트되는지의 여부에 관계없이 개체가 손실되므로, GC 모듈(1390)은 이를 행하는 것이다. 일 구현에서, 현재 트랜잭션들의 서브 트랜잭션들 내에서 할당된 도달 불가능한 개체들에 대한 로그 엔트리들도 제거된다.

블록 2430에서, 판독 개체 로그 내의 각각의 엔트리에 대해, 엔트리가 참조하는 개체가 검사되며, 개체가 이미 갱신 개체 로그 내에 있고 판독 개체 및 갱신 개체 로그들의 버전 번호들이 그 개체에 대해 일치하는 경우에는 판독 개체 로그 엔트리가 제거될 수 있다. 이 프로세스는 개체가 최초로 판독 개체 로그에 추가된 때, 및 개체가 최초로 갱신 개체 로그에 추가된 때를 식별할 수 있다. 어느 경우에나, GC는 포함된 판독 개체 로그 엔트리들을 제거한다.

블록 2440에서, GC 모듈(1390)은 중복 엔트리들을 허용하는 STM 구현들에서 판독 개체 로그로부터 중복 엔트리들을 제거한다. 복제 판독 개체 로그 엔트리 제거의 예시적인 프로세스가 도 25와 관련하여 아래에 설명된다. 이어서, 블록 2450에서, GC 모듈(1390)은 복귀 로그 내의 엔트리들을 검토하고, 로그 내의 "이전 값"을 로깅된 메모리 위치의 현재 값과 비교한다. 이들이 일치하는 경우, 값은 변경되지 않았으며, 복귀 로그 엔트리를 유지할 이유가 없으므로, GC 모듈(1390)은 이들 엔트리를 제거한다.

도 25는 복제 판독 개체 로그 엔트리들을 제거하기 위한 쓰레기 수집 모듈(1390)에 의해 수행되는 하나의 예시적인 프로세스(2500)를 나타내는 흐름도이다. 도 25의 프로세스는 도 24의 블록 2440에 대응한다. 다양한 구현에서, 도시된 프로세스 블록들은 병합되거나, 서브 블록들로 분할되거나, 생략될 수 있다. 도 25의 프로세스는 판독 개체 로그 엔트리는 개체가 현재의 트랜잭션 내에서 판독을 위해 개방되었다는 것만을 기록한다는 사실을 이용한다. 이것은 단일 개체에 대한 다수의 엔트리를 불필요하게 하며, 따라서 GC 동안 이들 엔트리를 제거하는 것이 이롭다.

도 25의 프로세스는 쓰레기 수집 동안 각각의 개체에 대해 유지되는 단일 판독 비트 플래그를 이용한다. 일 구현에서, 이 플래그는 STM 워드가 유지되는 방법과 유사하게 실행시간 시스템에 의해 유지된다. 다른 구현에서, GC 모듈(1390)은 GC 시간에 각각의 개체에 대한 플래그들을 유지한다. 프로세스는 블록 2510에서 시작되어, GC 모듈(1390)은 로그 내의 제1 엔트리에서 판독 개체 로그를 줄이기 시작한다. 이어서, 블록 2520에서, 현재 검토되고 있는 엔트리에 의해 참조되는 개체가 검토된다. 블록 2525에서, GC 모듈(1390)은 개체의 판독 비트가 설정되었는지를 판정한다. 그렇지 않은 경우, 현재의 엔트리는 개체에 대한 제1 엔트리인 것으로 가정된다. 따라서, 블록 2530에서, 판독 비트가 설정되고 엔트리가 그대로 남겨진다. 그러나, GC 모듈(1390)이 판독 비트가 블록 2540에서 이전에 설정된 것으로 판정하는 경우, 현재의 엔트리는 개체에 대한 이전 엔트리의 여분이므로, 모듈은 현재 엔트리를 제거한다. 일 구현에서, 이 제거는 제거되는 엔트리들의 위치들에 유지되는 엔트리를 복사함으로써 적절히 수행된다. 다른 구현들에서, 불필요한 경우 엔트리들은 이동되지 않고, 단지 할당 해제된다. 이어서, 프로세스는 판정 블록 2545로 계속되어, 모듈은 판독 개체 로그 내에 추가 엔트리들이 존재하는지를 판정한다. 그러한 경우, 프로세스는 계속된다. 그렇지 않은 경우, 프로세스는 종료된다.

7. 컴퓨팅 환경

전술한 소프트웨어 트랜잭션 메모리 기술들은 임의의 다양한 컴퓨팅 장치 상에서 수행될 수 있다. 기술들은 하드웨어 회로는 물론, 도 16에 도시된 바와 같은 컴퓨터 또는 다른 컴퓨팅 환경 내에서 실행되는 소프트웨어에서 구현될 수 있다.

도 26은 설명된 실시예들이 구현될 수 있는 적절한 컴퓨팅 환경(2600)의 일반 예를 나타낸다. 본 발명은 다양한 범용 또는 특수 목적의 컴퓨팅 환경에서 구현될 수 있으므로, 컴퓨팅 환경(2600)은 본 발명의 용도 또는 기능성의 범위에 관해 어떤 제한을 암시하고자 하는 것이 아니다.

도 26을 참조하면, 컴퓨팅 환경(2600)은 적어도 하나의 처리 장치(2610) 및 메모리(2620)를 포함한다. 도 26에서, 이러한 가장 기본적인 구성(2630)은 점선 내에 포함된다. 처리 장치(2610)은 컴퓨터 실행가능 명령들을 실행하며, 실제 또는 가상 프로세서일 수 있다. 다중 처리 시스템에서는, 처리 능력을 향상시키기 위해 다수의 처리 장치가 컴퓨터 실행가능 명령들을 실행한다. 메모리(2620)는 휘발성 메모리(예를 들어, 레지스터, 캐시, RAM), 비휘발성 메모리(예를 들어, ROM, EEPROM, 플래시 메모리 등), 또는 이 둘의 소정 조합일 수 있다. 메모리(2620)는 설명된 기술들을 구현하는 소프트웨어(2680)를 저장한다.

컴퓨팅 환경은 추가 특징을 가질 수 있다. 예를 들어, 컴퓨팅 환경(2600)은 저장 장치(2640), 하나 이상의 입력 장치(2650), 하나 이상의 출력 장치(2660), 및 하나 이상의 통신 접속(2670)을 포함한다. 버스, 컨트롤러, 또는 네트워크와 같은 상호접속 메커니즘(도시되지 않음)은 컴퓨팅 환경(2600)의 컴포넌트들을 상호접속한다. 통상적으로, 운영 체제 소프트웨어(도시되지 않음)는 컴퓨팅 환경(2600)에서 실행되는 다른 소프트웨어에 대한 운영 환경을 제공하며, 컴퓨팅 환경(2600)의 컴포넌트들의 활동들을 조정한다.

저장 장치(2640)는 이동식 또는 비이동식일 수 있으며, 자기 디스크, 자기 테이프 또는 카세트, CD-ROM, CD-RW, DVD, 또는 정보를 저장하는 데 사용될 수 있고 컴퓨팅 환경(2600) 내에서 액세스될 수 있는 임의의 기타 매체를 포함한다. 저장 장치(2640)는 설명된 기술들을 구현하는 소프트웨어(2680)를 위한 명령들을 저장한다.

입력 장치(들)(2650)는 키보드, 마우스, 펜 또는 트랙볼과 같은 터치 입력 장치, 음성 입력 장치, 스캐닝 장치, 또는 컴퓨팅 환경(2600)에 입력을 제공하는 다른 장치일 수 있다. 오디오에 대해, 입력 장치(들)(2650)는 아날로그 또는 디지털 형태의 오디오 입력을 수신하는 사운드 카드 또는 유사한 장치, 또는 컴퓨팅 환경에 오디오 샘플을 제공하는 CD-ROM 판독기일 수 있다. 출력 장치(들)(2660)는 표시 장치, 프린터, 스피커, CD 기록기, 또는 컴퓨팅 환경(2600)으로부터의 출력을 제공하는 다른 장치일 수 있다.

통신 접속(들)(2670)은 통신 매체를 통한 다른 컴퓨팅 엔티티와의 통신을 가능하게 한다. 통신 매체는 컴퓨터 실행가능 명령들, 압축 오디오 또는 비디오 정보, 또는 기타 데이터와 같은 정보를 피변조 데이터 신호(modulated data signal) 내에서 전송한다. 피변조 데이터 신호는 신호 내에 정보를 인코딩하도록 신호의 특성 세트 중 하나 이상이 설정 또는 변경시킨 신호이다. 예를 들어, 통신 매체는 전기, 광학, RF, 적외선, 음향, 또는 다른 캐리어로 구현되는 유선 또는 무선 기술을 포함하지만 이에 제한되는 것은 아니다.

여기에 설명되는 기술들은 컴퓨터 판독가능 매체와 일반적으로 관련하여 설명될 수 있다. 컴퓨터 판독가능 매체는 컴퓨팅 환경에서 액세스될 수 있는 임의의 이용 가능 매체이다. 예를 들어, 컴퓨팅 환경(2600)과 관련하여, 컴퓨터 판독가능 매체는 메모리(2620), 저장 장치(2640), 통신 매체 및 이들의 임의 조합을 포함하지만 이에 제한되는 것은 아니다.

여기서 기술들은 프로그램 모듈에 포함되고 컴퓨팅 환경에서 타겟 실제 또는 가상 프로세서 상에서 실행되는 것들과 같은 컴퓨터 실행가능 명령들과 일반적으로 관련하여 설명될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 라이브러리, 개체, 클래스, 컴포넌트, 데이터 구조 등을 포함한다. 프로그램 모듈의 기능은 다양한 실시예에서 필요에 따라 조합되거나, 프로그램 모듈들 사이에 분산될 수 있다. 프로그램 모듈을 위한 컴퓨터 실행가능 명령들은 로컬 또는 분산 컴퓨팅 환경에서 실행될 수 있다.

설명을 위해, 상세한 설명은 "판정한다", "생성한다", "비교한다" 및 "기입한다"와 같은 용어를 사용하여, 컴퓨팅 환경에서의 컴퓨터 동작들을 설명한다. 이러한 용어들은 컴퓨터에 의해 수행되는 동작들에 대한 고 레벨 추상화들이며, 인간에 의해 수행되는 행위들과 혼동되어서는 안 된다. 이러한 용어들에 대응하는 실제 컴퓨터 동작들은 구현에 따라 다르다.

여기에 설명되는 본 발명의 많은 가능한 변형에 비추어, 아래의 청구범위 및 그의 균등물의 범위 내에 있을 수 있는 모든 실시예들을 본 발명으로서 청구한다.

Claims (43)

1. 처리 장치, 및 소프트웨어 트랜잭션 메모리 연산들에 대한 지식을 갖도록 구성된 컴파일러를 포함하는 컴퓨터 시스템에서, 소프트웨어 트랜잭션 메모리 블록들을 포함하는 프로그램을 컴파일하기 위해 수행되는 방법으로서,

   소프트웨어 트랜잭션 메모리 명령들을 포함하는 최적화된 프로그램을 생성하도록 상기 프로그램을 최적화하는 단계(460); 및

   상기 최적화된 프로그램을 컴파일하는 단계(340)

   를 포함하는 방법.
2. 제1항에 있어서,

   상기 프로그램을 최적화하는 단계는

   직접 액세스 소프트웨어 트랜잭션 메모리 명령들을 상기 프로그램의 상기 소프트웨어 트랜잭션 메모리 블록들에 삽입하는 단계; 및

   최적화된 프로그램을 생성하도록 상기 소프트웨어 트랜잭션 메모리 명령들을 포함하는 상기 프로그램 상에서 최적화들을 수행하는 단계 - 이에 따라, 상기 최적화들 중 적어도 일부는 상기 직접 액세스 소프트웨어 트랜잭션 메모리 명령들 상에서 고유하게 동작하도록 구성됨 -

   를 포함하는 방법.
3. 제2항에 있어서, 상기 최적화들을 수행하는 단계는 분해된 소프트웨어 트랜잭션 메모리 명령들 상에서 동작하도록 수정된 공통 하위 표현식 제거 프로시저를 수행하는 단계를 포함하는 방법.
4. 제3항에 있어서, 상기 공통 하위 표현식 제거 프로시저는 동일 트랜잭션 내에서 판독을 위해 개체를 개방하는 명령이 갱신을 위해 개체를 개방하는 명령 후에 제거되도록 수정되는 방법.
5. 제3항에 있어서, 상기 공통 하위 표현식 제거 프로시저는 메모리 어드레스들에 대한 중복 판독들 및 기입들, 및 트랜잭션 내의 메모리 어드레스들에 대한 중복 로그들이 제거되도록 수정되는 방법.
6. 제5항에 있어서, 상기 공통 하위 표현식 제거 프로시저는 제1 트랜잭션 내의 판독들 및 기입들이 제2 트랜잭션 내의 판독들 및 기입들에 의해 중복되는 경우에 제거되도록 더 수정되고, 상기 제1 트랜잭션은 상기 제2 트랜잭션 내에 중첩되는 방법.
7. 제2항에 있어서, 상기 최적화들을 수행하는 단계는 코드 이동 최적화들을 수행하는 단계를 포함하는 방법.
8. 제2항에 있어서, 상기 최적화들을 수행하는 단계는 개체에 대한 트랜잭션 메모리 액세스들과 적어도 하나의 비 트랜잭션 메모리 연산 간의 아토믹성을 보장하는 하나 이상의 트랜잭션 메모리 연산들을 갖는 메모리 트랜잭션의 외부에서 상기 개체에 액세스하는 상기 비 트랜잭션 메모리 연산을 증대시키는 단계를 포함하는 방법.
9. 제8항에 있어서,

   상기 비 트랜잭션 메모리 연산을 증대시키는 단계는

   상기 비 트랜잭션 메모리 연산에 의한 액세스를 위해 상기 개체를 개방하는 개방 연산을 상기 비 트랜잭션 메모리 연산 전에 삽입하는 단계; 및

   상기 비 트랜잭션 메모리 연산의 실행 동안 상기 개체에 대한 충돌 액세스가 존재하였는지를 판정하는 커미트 연산을 상기 비 트랜잭션 메모리 연산 후에 삽입하는 단계

   를 포함하는 방법.
10. 제9항에 있어서,

    상기 비 트랜잭션 메모리 연산은 판독 연산이고,

    상기 개방 연산은 상기 비 트랜잭션 메모리 연산의 실행 전에 상기 개체의 상태의 지시를 검색하도록 구성되고,

    상기 커미트 연산은 상기 비 트랜잭션 메모리 연산의 실행 후에 상기 개체의 상태의 지시를 검색하고, 상기 개체의 상태가 충돌 액세스를 지시하는 경우에는 판독이 가능할 때까지 상기 개방, 판독 및 커미트 연산들이 루프 실행되게 하도록 구성되는 방법.
11. 제9항에 있어서,

    상기 비 트랜잭션 메모리 연산은 기입 연산이고,

    상기 개방 연산은 상기 개체에 대한 기입 액세스를 취득하도록 구성되고,

    상기 커미트 연산은 상기 개체에 대해 행해지는 기입을 커미트하도록 구성되는 방법.
12. 제9항에 있어서, 개방 및 커미트 커맨드들은 상기 비 트랜잭션 메모리 연산이 아토믹하게 수행되는 것을 보장하기 위해 상기 개체에 대한 동기화를 이용하는 방법.
13. 제9항에 있어서, 개방 커맨드는 액세스를 위해 상기 개체를 개방할 수 있을 때까지 차단되는 방법.
14. 제8항에 있어서, 메모리 트랜잭션들 외부에서 개체들에 액세스하는 하나 이상의 메모리 연산을 식별하는 단계를 더 포함하는 방법.
15. 제14항에 있어서,

    상기 하나 이상의 메모리 연산을 식별하는 단계는

    상기 소프트웨어의 실행 동안 트랜잭션 메모리 연산들에 의해 액세스될 수 있는 필드들을 결정하기 위해 트랜잭션 메모리 액세스들을 분석하는 단계;

    트랜잭션 메모리 연산들에 의해 액세스될 수 있는 필드들에 액세스하는 하나 이상의 비 트랜잭션 메모리 연산을 식별하는 단계

    를 포함하는 방법.
16. 제15항에 있어서, 트랜잭션 메모리 연산들에 의해 액세스되지 않도록 보증되는 임의의 필드에 대해, 당해 필드에 액세스하는 비 트랜잭션 메모리 연산들의 증대가 방지되는 방법.
17. 제16항에 있어서, 상기 하나 이상의 트랜잭션 메모리 연산을 갖는 메모리 트랜잭션의 외부에서 개체에 액세스하는 비 트랜잭션 메모리 연산을 증대시키는 단계는 상기 비 트랜잭션 메모리 연산 주위에 아토믹 메모리 트랜잭션 블록들을 삽입하는 단계를 포함하는 방법.
18. 제2항에 있어서,

    상기 최적화들을 수행하는 단계는

    프로그램 포인트들의 세트에서 트랜잭션들 내에 새로 할당된 개체들에 항상 속박되는 개체들에 대한 참조들을 식별하는 단계; 및

    상기 식별된 참조들을 통해 도달된 개체들에 대한 소프트웨어 트랜잭션 메모리 연산들을 방지하는 단계 - 상기 연산들은 상기 트랜잭션들 외부에서 영향을 미치지 않음 -

    를 포함하는 방법.
19. 제18항에 있어서, 상기 프로그램 포인트들의 세트에서 새로 할당된 개체들에 항상 속박되는 개체들에 대한 참조들을 식별하는 단계는 프로시저 호출들을 통해 발생하는 방법.
20. 제19항에 있어서, 상기 프로그램 포인트들의 세트에서 새로 할당된 개체들에 항상 속박되는 개체들에 대한 참조들을 식별하는 단계는 상기 프로그램에 대한 순방향 데이터 흐름 분석을 수행하는 단계를 포함하는 방법.
21. 제20항에 있어서, 상기 순방향 데이터 흐름 분석은, 각각의 기본 블록에 대해, 상기 기본 블록 내의 각각의 변수에 대해, 상기 기본 블록 내의 위치에서, 상기 변수가 새로 할당된 개체들에 항상 할당되는 것으로 공지되는지, 아마도 상기 트랜잭션 외부에 할당된 개체에 할당될 수 있는지, 또는 상기 변수에 대한 정보가 공지되지 않는지를 나타나는 데이터 구조를 유지하는 단계를 포함하는 방법.
22. 제21항에 있어서, 상기 데이터 구조는 각각의 참조에서 각각의 참조에 대해 유지되는 데이터로의 맵을 포함하고, 각각의 참조에 대해 유지되는 상기 데이터는 격자 값 및 참조들 사이의 종속성들을 포함하는 갱신 가능 셀을 포함하는 방법.
23. 제22항에 있어서, 상기 데이터 구조를 유지하는 단계는 상기 데이터 흐름 분석이 진행될 때 상기 참조들 사이의 종속성들을 이용하여 상기 격자 값들의 갱신 가능 셀들을 통해 정보를 전달하는 단계를 포함하는 방법.
24. 제23항에 있어서, 상기 정보를 전달하는 단계는 변수들에서 격자 값들의 갱신 가능 셀들로의 맵 내의 맵핑되지 않은 변수들에 대한 프로그램 문장들이 분석되기 전에 상기 맵핑되지 않은 변수들에 대한 정보를 전달하는 단계를 포함하는 방법.
25. 제18항에 있어서, 상기 식별된 참조들을 통해 도달된 개체들에 대한 소프트웨어 트랜잭션 메모리 연산들을 방지하는 단계 - 상기 연산들은 상기 트랜잭션 외부에서 영향을 미치지 않음 - 는 각각의 참조에 대해, 상기 참조를 통한 갱신 연산들을, 분해된 소프트웨어 트랜잭션 메모리 연산들로 분해될 때, 갱신 로그 연산들을 포함하지 않는 갱신 연산들로 대체하는 단계를 포함하는 방법.
26. 제18항에 있어서, 상기 식별된 참조들을 통해 도달된 개체들에 대한 소프트 웨어 트랜잭션 메모리 연산들을 방지하는 단계 - 상기 연산들은 상기 트랜잭션 외부에서 영향을 미치지 않음 - 는 소프트웨어 트랜잭션 메모리 연산들이 분해된 소프트웨어 트랜잭션 메모리 연산들로 분해된 후에 상기 식별된 참조들을 통해 연산하는 분해된 로그 연산들을 제거하는 단계를 포함하는 방법.
27. 제18항에 있어서,

    상기 식별된 참조들 중 어느 것이 상기 트랜잭션 후에 액세스될 수 없는 개체들에 대한 것인지를 판정하는 단계를 더 포함하고,

    상기 식별된 참조들을 통해 도달된 개체들에 대한 소프트웨어 트랜잭션 메모리 연산들을 방지하는 단계 - 상기 연산들은 상기 트랜잭션 외부에서 영향을 미치지 않음 - 는 상기 판정된 참조들을 통해 판독 또는 갱신을 위해 개체들을 개방하는 소프트웨어 트랜잭션 메모리 연산들을 제거하는 단계를 포함하는 방법.
28. 제2항에 있어서,

    상기 최적화들을 수행하는 단계는

    실행 동안 갱신을 위해 참조를 개방하는 제1 소프트웨어 트랜잭션 메모리 명령이 이어지는 것으로 공지된, 판독을 위해 상기 참조를 개방하는 소프트웨어 트랜잭션 메모리 명령을 찾는 단계; 및

    판독을 위해 상기 참조를 개방하는 상기 명령을, 갱신을 위해 상기 참조를 개방하는 제2 명령으로 대체하는 단계

    를 포함하는 방법.
29. 제28항에 있어서, 갱신을 위해 상기 참조를 개방하는 상기 제1 명령을 제거하는 단계를 더 포함하는 방법.
30. 제29항에 있어서, 상기 제1 명령은 공통 하위 표현식 제거를 이용하여 상기 제1 명령을 포함하는 중복 명령들을 제거하는 단계를 포함하는 방법.
31. 제28항에 있어서, 상기 소프트웨어는 제어 흐름 그래프로 표현되고, 상기 방법은 상기 제어 흐름 그래프 상에서 수행되는 방법.
32. 제31항에 있어서,

    상기 판독을 위해 참조를 개방하는 명령을 찾는 단계는

    상기 제어 흐름 그래프 내의 기본 블록들에 대해

    판독을 위해 참조를 개방하는 명령을 식별하는 단계;

    상기 참조를 기록하는 단계;

    상기 식별된 명령으로부터 상기 기본 블록을 통해 순방향으로 스캐닝하는 단계;

    상기 참조에 대한 할당이 발견될 때, 상기 식별된 명령에 대한 스캐닝을 중지하는 단계; 및

    갱신을 위해 상기 참조를 개방하는 명령이 발견될 때, 상기 식별된 명령을 대체하도록 진행하는 단계

    를 포함하는 방법.
33. 제31항에 있어서,

    상기 판독을 위해 참조를 개방하는 명령을 찾는 단계는

    상기 제어 흐름 그래프 내의 기본 블록들에 대해

    갱신을 위해 참조를 개방하는 명령을 식별하는 단계;

    상기 참조를 기록하는 단계;

    상기 식별된 명령으로부터 상기 기본 블록을 통해 역방향으로 스캐닝하는 단계;

    상기 참조에 대한 할당이 발견될 때, 상기 식별된 명령에 대한 스캐닝을 중지하는 단계; 및

    판독을 위해 상기 참조를 개방하는 명령이 발견될 때, 판독을 위해 상기 참조를 개방하는 상기 발견된 명령을 대체하도록 진행하는 단계

    를 포함하는 방법.
34. 제31항에 있어서, 상기 판독을 위해 참조를 개방하는 명령을 찾는 단계는 갱신을 위해 참조를 개방하는 명령들에 의해 중복되는, 판독을 위해 참조를 개방하는 명령들에 대한 기본 블록 경계들을 통해 검색하는 데이터 흐름 분석을 수행하는 단 계를 포함하는 방법.
35. 제34항에 있어서,

    상기 데이터 흐름 분석을 수행하는 단계는

    갱신을 위해 개방된 참조들을 참조하는 것으로 공지된 변수들의 세트를 상기 제어 흐름 그래프 내의 각각의 기본 블록의 경계에 유지하는 단계;

    각각의 기본 블록에 대해,

    상기 제어 흐름 그래프를 통해 역방향으로 스캐닝하는 단계;

    갱신을 위해 참조를 개방하는 명령이 특정 변수에 대해 발견될 때, 상기 변수를 상기 기본 블록에 대한 변수들의 세트에 추가하는 단계;

    특정 변수에 대한 정의가 발견될 때, 상기 기본 블록에 대한 변수들의 세트로부터 상기 변수를 제거하는 단계;

    상기 기본 블록의 시작이 발견될 때, 상기 기본 블록에 대한 변수 세트와 상기 기본 블록에 직접 이르는 기본 블록들의 끝에 저장된 변수 세트들을 교차시키는 단계;

    각각의 기본 블록에 대해 안정된 변수들의 세트가 생성될 때까지 상기 프로세스를 반복하는 단계; 및

    각각의 기본 블록에 대해, 판독을 위해 상기 기본 블록에 대한 변수들의 세트에 의해 참조되는 참조들을 개방하는 명령들을 중복 명령들로서 간주하는 단계

    를 포함하는 방법.
36. 제2항에 있어서,

    상기 최적화들을 수행하는 단계는

    상기 프로그램 내의 하나 이상의 프로시저의 외부에서 최적화될 수 있는 하나 이상의 소프트웨어 트랜잭션 메모리 연산을 포함하는 상기 프로시저를 식별하는 단계;

    상기 하나 이상의 프로시저 각각에 대해, 상기 프로시저의 복제 버전의 외부에서 최적화될 수 있는 소프트웨어 트랜잭션 메모리 연산들의 호출을 허가하는 상기 복제 버전을 생성하는 단계;

    상기 프로시저들의 외부에서 최적화될 수 있는 하나 이상의 소프트웨어 트랜잭션 메모리 연산을 이동시키는 단계; 및

    상기 하나 이상의 프로시저 각각에 대한 호출들을 그의 복제 버전에 대한 호출들로 대체하는 단계

    를 포함하는 방법.
37. 제36항에 있어서, 최적화될 수 있는 하나 이상의 소프트웨어 트랜잭션 메모리 연산 중에서 중복들을 제거함으로써 상기 프로그램을 최적화하는 단계를 더 포함하는 방법.
38. 제37항에 있어서, 상기 프로그램을 최적화하는 단계는 상기 프로그램 상에서 공통 하위 표현식 제거를 수행하는 단계를 포함하는 방법.
39. 제37항에 있어서, 상기 최적화될 수 있는 하나 이상의 소프트웨어 트랜잭션 메모리 연산은 트랜잭션 관리자를 취득하기 위한 연산들을 포함하는 방법.
40. 제39항에 있어서, 트랜잭션 관리자를 취득하기 위한 연산들을 포함하는 상기 프로시저들의 복제 버전들은 트랜잭션 관리자의 인스턴스들을 입력들로서 취하는 프로시저들을 포함하는 방법.
41. 제37항에 있어서, 상기 최적화될 수 있는 하나 이상의 소프트웨어 트랜잭션 메모리 연산은 판독 또는 갱신을 위해 참조들을 개방하는 연산들을 포함하고, 상기 참조들은 입력들로서 상기 프로시저들로 전달되는 방법.
42. 제41항에 있어서, 판독 또는 갱신을 위해 참조들을 개방하는 연산들을 포함하는 프로시저들의 복제 버전들은 상기 프로시저들이 호출되기 전에 개방되는 참조들에 의존하는 프로시저들을 포함하는 방법.
43. 제42항에 있어서, 판독 또는 갱신을 위해 참조들을 개방하는 연산들을 포함하는 프로시저들의 복제 버전들을 생성하는 단계는 어느 프로시저들이 상기 프로시저들의 시작에서 공지되는 참조들에 대한 판독 또는 갱신을 위해 참조들을 개방하 는 연산들을 포함하는지를 판정하기 위해 역방향 데이터 흐름 분석을 수행하는 단계를 포함하는 방법.

Images