KR102123711B1 - 공유 및 관리 메모리 통합 액세스 - Google Patents

Abstract

다수의 컴퓨팅 엔티티들 각각이 가비지 수집의 대상이 되는 대응하는 엔티티-특유의 부분(entity-specific portion)을 가지는 관리 메모리(managed memory)가 제공된다. 변경불가능 버퍼(immutable buffer)가 관리 메모리 외부에 위치해 있다. 주어진 컴퓨팅 엔티티에 대해, 대응하는 관리 메모리 부분은 특정의 컴퓨팅 엔티티에 의해서는 액세스될 수 있지만 다른 다수의 컴퓨팅 엔티티들에 의해서는 액세스될 수 없는 엔티티-특유의 객체들을 포함한다. 엔티티-특유의 관리 메모리 부분들 중 하나 이상에 대해, 그 부분은 또한 변경불가능 버퍼와 같은 공유 메모리에 대한 참조를 포함한다. 그 참조는 가비지 컬렉터(garbage collector)에 의해 무시되도록 구조화(structure)되어 있지만, 그 참조가 관리 메모리 부분 내의 통상의 객체(normal object)인 것처럼 보일 수 있다. 이와 같이, 컴퓨팅 엔티티가 관리 메모리 내의 통상의 객체(regular object)에 액세스하는 방법들이 컴퓨팅 엔티티가 공유 메모리에 액세스하는 방법과 유사한 통합 메모리 액세스 모델(unified memory access model)이 가능하게 된다.

Description

공유 및 관리 메모리 통합 액세스{SHARED AND MANAGED MEMORY UNIFIED ACCESS}

컴퓨터 운영 체제 성능은 종종 운영 체제가 주어진 시간 구간에 걸쳐 지속할 수 있는 최대 I/O(input/output) 동작 속도("I/O 성능"이라고도 함)에 의해 특징지워진다. 그 결과, 운영 체제는 I/O 성능을 증대시키기 위해 각종의 공지된 메커니즘들을 이용한다.

운영 체제가 종래에는 메모리가 어떻게 조작되는지에 대한 아주 미세한 제어를 시스템 프로그래머에게 제공하는 비관리 언어(unmanaged language)(어셈블리어, C, C++ 등)를 사용하여 작성되었다. 검사되지 않는 포인터(unchecked pointer)의 사용은 운영 체제의 오버헤드를 최소화하고 증가된 처리량 또는 감소된 대기시간을 가능하게 하기 위해 사용될 수 있다. 이들 검사되지 않는 포인터의 사용의 단점은 포인터가 생성하고 추론하기 어려워, 신뢰할 수 없는 소프트웨어 및 보안 취약성을 가져온다는 것이다.

소프트웨어를 관리 프로그래밍 언어(managed programming language)로 작성하는 것은 상당한 정확성 이점 및 개발 시간 효율성을 제공한다. 이들 관리 언어는 프로그래머가 많은 종류의 소프트웨어 결함들을 야기하는 것을 방지하여, 향상된 소프트웨어 품질 및 감소된 개발 시간에 이르게 한다. 운영 체제 정확성은 신뢰할 수 있고 안전한 컴퓨팅 경험을 제공하는 데 아주 중요한 요소이다. 따라서, 관리 언어를 사용하여 운영 체제를 제작하는 것은, 운영 체제 안정성이 향상될 수 있고 개발 비용이 감소될 수 있기 때문에, 매력적인 제안이다.

이들 이점을 달성하기 위해, 관리 프로그래밍 언어는 프로그래머에 의해 작성되는 소스 코드와 물리적 컴퓨터 시스템의 원시 기계 리소스(raw machine resource) 사이에 추상화 계층을 삽입한다. 이 추상화 계층은 일반적으로 프로그래머가 작성하도록 허용되어 있는 것을 제약하고, 그렇게 함에 있어서, 모든 종류의 잠재적 결함들을 제거하는 역할을 한다. 안타깝게도, 이 추상화 계층은 제작되고 있는 소프트웨어의 성능을 해칠 수 있는 오버헤드를 유입시킨다. 그 결과, 통상의 가정은 관리 언어가 정확성 결함을 성능 결함과 맞바꾸는 것이다. 따라서, 관리 언어로 작성되는 소프트웨어는 종종 본질적으로 비관리 언어로 작성되는 소프트웨어보다 더 느린 것으로 간주된다.

관리 코드 운영 체제(managed code operating system)에 영향을 미치는 특정의 문제점은 데이터가 시스템을 통해 이동할 때 본질적으로 계층들 사이에서 데이터를 복사할 필요가 있다는 것이다. 이것은 시스템의 별개의 컴포넌트들이 상이한 격리 컨텍스트(isolation context)에 존재하고 이들 격리 컨텍스트에서 벗어나는 명확한 메커니즘이 없다는 사실에 의해 유발된다.

본 명세서에 기술된 적어도 하나의 실시예에 따르면, 시스템은 다수의 컴퓨팅 엔티티들 각각이 가비지 수집(garbage collection)의 대상이 되는 대응하는 엔티티-특유의 관리 메모리 부분(entity-specific managed memory portion)을 가지는 관리 메모리(managed memory)를 가진다. 변경불가능 버퍼(immutable buffer)는 관리 메모리의 외부에 위치해 있다. 주어진 컴퓨팅 엔티티에 대해, 대응하는 관리 메모리 부분은 특정의 컴퓨팅 엔티티에 의해서는 액세스될 수 있지만 자기 자신의 엔티티-특유의 관리 메모리 부분들을 가지는 다른 다수의 컴퓨팅 엔티티들에 의해서는 액세스될 수 없는 하나 이상의 엔티티-특유의 객체(entity-specific object)들을 포함한다.

엔티티-특유의 관리 메모리 부분들 중 하나 이상에 대해, 그 부분은 또한 공유 메모리(shared memory)에 대한 참조를 포함한다. 하나의 실시예에서, 그 공유 메모리는 변경불가능 버퍼일 수 있다. 그 참조는 가비지 컬렉터(garbage collector)에 의해 무시되도록 구조화(structure)되어 있지만, 그 참조가 관리 메모리 부분 내의 통상의 객체(normal object)인 것처럼 보일 수 있다. 예를 들어, 아마도 그 참조는 배열 요소(array element)이다. 그렇지만, 가비지 컬렉터는 다른 객체들과 그 참조를 구별할 수 있다. 일례로서, 가비지 컬렉터는 배열에서 주소를 찾을 수 있고, 그 주소가 관리 메모리의 외부에 있는 위치인 경우, 가비지 컬렉터는 그 참조에 대해 가비지 수집을 수행하지 않는다.

이와 같이, 컴퓨팅 엔티티가 관리 메모리 내의 통상의 객체(regular object)에 액세스하는 방법들이 컴퓨팅 엔티티가 공유 메모리에 액세스하는 방법과 유사한 통합 메모리 액세스 모델(unified memory access model)이 가능하게 된다. 이 발명의 내용은 청구된 발명 요지의 핵심적인 특징들 또는 필수적인 특징들을 확인하기 위한 것이 아니며, 청구된 발명 요지의 범주를 정하는 데 보조 수단으로 사용되기 위한 것도 아니다.

앞서 언급된 장점들 및 특징들과 기타 장점들 및 특징들이 달성될 수 있는 방식을 설명하기 위해, 다양한 실시예들의 보다 상세한 설명이 첨부 도면을 참조하여 이루어질 것이다. 이들 도면이 예시적인 실시예만을 도시하고 있고 따라서 본 발명의 범주를 제한하는 것으로 간주되어서는 안된다는 것을 이해하면서, 첨부 도면을 사용하여 실시예들이 보다 구체적이고 상세하게 기술되고 설명될 것이다.
도 1은 본 명세서에 기술된 일부 실시예들이 이용될 수 있는 컴퓨팅 시스템을 추상적으로 나타낸 도면.
도 2는 변경불가능 버퍼를 제공하는 방법의 플로우차트.
도 3a는 버퍼를 채우는 프로세스가 행해지는 환경을 나타낸 도면.
도 3b는 채워진 버퍼가 변경불가능으로 되는 환경을 나타낸 도면.
도 4는 변경불가능 버퍼를 사용하는 방법의 플로우차트.
도 5는 상이한 컴퓨팅 엔티티들이 변경불가능 버퍼에 대한 상이한 뷰를 가지는 환경을 나타낸 도면.
도 6은 하나의 컴퓨팅 엔티티로부터 그 다음 컴퓨팅 엔티티로 변경불가능 데이터를 전달하는 방법의 플로우차트.
도 7은 데이터의 스트림이 스트림 소스로부터 스트림 버퍼 내로 제공되고 이어서 버퍼로부터 스트림 소비자로 제공되는 스트리밍 환경을 나타낸 도면.
도 8은 제2 컴퓨팅 엔티티가 제1 컴퓨팅 엔티티의 캐시를 통해 캐시를 획득하는 환경을 나타낸 도면.
도 9는 제2 컴퓨팅 엔티티가 처음으로 제1 컴퓨팅 엔티티에 의해 지원되는 캐시로부터 읽는 방법의 플로우차트.
도 10은 제2 컴퓨팅 엔티티가 차후에 제1 컴퓨팅 엔티티에 의해 지원되는 캐시로부터 읽는 방법의 플로우차트.
도 11은 제1 컴퓨팅 엔티티[또는 지원 캐시(backing cache)]가 축출(eviction)을 수행하는 방법의 플로우차트.
도 12는 예시적인 관리 코드 시스템(managed code system)을 나타낸 도면.
도 13은 2 개의 별개의 스팬(span)이 배열을 가리키고 있고 애플리케이션으로 하여금 배열의 부분들을 상이한 형식(type)으로서 볼 수 있게 하는 바이트들의 통상의 관리 배열(managed array)을 나타낸 도면.

본 명세서에 기술된 실시예들에 따르면, 관리 운영 체제(managed operating system)에서 무복사(zero-copy) I/O(input/output) 의미(semantics)를 격상(promote)시키는 메커니즘들이 기술되어 있다. 이러한 메커니즘들 중 일부는 관리 코드 운영 체제에서 뿐만 아니라, 비관리 코드 운영 체제(unmanaged code operating system)에서도 사용될 수 있다. 이 메커니즘들은 상호 배타적이지 않은데, 왜냐하면 그 메커니즘들 중 하나, 일부 또는 심지어 전부가 무복사 I/O 의미를 훨씬 더 격상시키기 위해 결합될 수 있기 때문이다.

"무복사"는 데이터를 복사할 필요 없이 데이터가 메모리에 기입되고 많은 추상화 계층들을 통해 전파되는 것에 의해 시스템에 들어갈 수 있게 하도록 설계된 아키텍처를 지칭한다. 무복사 아키텍처는 데이터 복사가 일어나지 않는다는 것을 보장하지 않는다. 오히려, 이는 대부분의 I/O 동작들이 복사 없이 행해질 수 있도록 보장하는 메커니즘을 시행할 뿐이다. 이 설명에서 그리고 청구범위에서, "메모리"가 전형적으로 휘발성 메모리인 임의의 랜덤 액세스 메모리로서 정의되어 있지만, 비휘발성 부분들도 포함할 수 있거나 아마도 완전히 비휘발성일 수 있다. 이 설명에서 그리고 청구범위에서, "메모리"는 컴퓨팅 시스템의 마이크로프로세서들에 의해 액세스가능한 그리고 DMA(direct memory access) 메커니즘을 통해 그래픽 제어기 또는 네트워크 인터페이스 제어기와 같은 하드웨어 디바이스들에 의해 액세스가능한 개개의 주소 지정 가능 장소(addressable location)들로 이루어진, 컴퓨팅 시스템의 주 저장 매체로서 정의되어 있다.

첫째, 공유 데이터의 변경불가능 버퍼를 사용하는 변경불가능 공유가능 무복사 벌크 데이터 메커니즘(immutable sharable zero-copy bulk data mechanism)이 기술될 것이다. 이러한 메커니즘은 복사 없이 컴퓨팅 시스템 전체에 걸쳐 대규모 데이터 버퍼의 전송을 가능하게 한다. 이 메커니즘은, 모두가 완전 무복사 의미(full zero-copy semantics)를 유지하면서, 효율적인 리소스 이용을 가능하게 하기 위해 완전 흐름 제어를 갖는 컴퓨팅 시스템 내에서의 데이터 스트림의 공유된 사용으로 추가로 확장될 것이다. 관리 코드 시스템의 현재의 형식 안전성(type safety)이 이들 메커니즘의 보다 즉각적인 구현을 가능하게 하지만, 비관리 코드 시스템(unmanaged code system) 내에서의 이들 메커니즘의 사용도 또한 이용될 수 있다.

둘째, 무복사 캐싱(zero-copy caching)을 위한 메커니즘이 기술될 것이다. 이러한 무복사 캐싱은 비관리 코드 시스템 및 관리 코드 시스템 둘 다에서 이용될 수 있다. 무복사 캐싱은 캐시에 들어가는 데이터는 물론, 캐시로부터 반환되는 데이터에 대한 무복사 의미를 특징으로 하는 범용 캐시 아키텍처를 생성하는 것을 가능하게 한다.

셋째, 관리 코드 시스템이 변경불가능 버퍼 또는 공유 데이터를 이용하는지 여부에 관계없이, 관리 코드 시스템의 성능을 추가로 향상시키는 몇 가지 메커니즘들이 기술될 것이다. 이러한 관리 코드 메커니즘은 균일 메모리 액세스(uniform memory access) 및 형식이 안전한 형식 변환(type-safe type casting)을 포함한다. 균일 메모리 액세스는 일관성있고 구성가능한 접근법을 사용하여 관리 코드가 관리 메모리 및 비관리 메모리(unmanaged memory)(I/O 버퍼에 대해 사용됨) 둘 다에 균일하게 액세스할 수 있게 한다. 형식이 안전한 형식 변환은, 완전 형식 안전성을 유지하면서, 메모리의 주어진 영역이 별개의 형식들로서 보일 수 있게 하기 위해 관리 코드가 포인터 변환(pointer casting)을 수행할 수 있게 한다.

컴퓨팅 시스템에 대한 어떤 서론적 논의가 도 1과 관련하여 기술될 것이다. 이어서, 앞서 열거한 메커니즘들이 도 2 내지 도 13과 관련하여 앞서 제공된 순서로 기술될 것이다.

컴퓨팅 시스템은 이제 점점 아주 다양한 형태들을 취하고 있다. 컴퓨팅 시스템은, 예를 들어, 핸드헬드 디바이스, 가전 제품, 랩톱 컴퓨터, 데스크톱 컴퓨터, 메인 프레임, 분산 컴퓨팅 시스템, 또는 심지어 종래에 컴퓨팅 시스템으로 간주되지 않았던 디바이스일 수 있다. 이 설명 및 청구 범위에서, "컴퓨팅 시스템"이라는 용어는 적어도 하나의 물리적 및 유형적 프로세서, 그리고 프로세서에 의해 실행될 수 있는 컴퓨터 실행가능 명령어들을 가질 수 있는 물리적 및 유형적 메모리를 포함하는 임의의 디바이스 또는 시스템(또는 이들의 조합)을 포함하는 것으로 광의적으로 정의된다. 메모리는 임의의 형태를 취할 수 있고, 컴퓨팅 시스템의 성질 및 형태에 의존할 수 있다. 컴퓨팅 시스템은 네트워크 환경에 걸쳐 분산되어 있을 수 있고 다수의 구성 컴퓨팅 시스템(constituent computing system)들을 포함할 수 있다.

도 1에 예시된 바와 같이, 그의 가장 기본적인 구성에서, 컴퓨팅 시스템(100)은 적어도 하나의 처리 유닛(102) 및 컴퓨터 판독가능 매체(104)를 포함한다. 컴퓨터 판독가능 매체(104)는 개념적으로 휘발성, 비휘발성, 또는 이 둘의 어떤 조합일 수 있는 물리적 시스템 메모리를 포함하는 것으로 생각될 수 있다. 컴퓨터 판독가능 매체(104)는 또한 개념적으로 비휘발성 대용량 저장소를 포함한다. 컴퓨팅 시스템이 분산되어 있는 경우, 처리, 메모리 및/또는 저장 기능도 분산되어 있을 수 있다.

본 명세서에서 사용되는 바와 같이, "실행가능 모듈" 또는 "실행가능 컴포넌트"라는 용어는 컴퓨팅 시스템 상에서 실행될 수 있는 소프트웨어 객체(software object), 루틴 또는 메서드를 지칭할 수 있다. 본 명세서에 기술된 상이한 컴포넌트들, 모듈들, 엔진들 및 서비스들이 컴퓨팅 시스템 상에서 (예컨대, 개별적인 스레드들로서) 실행되는 객체들 또는 프로세스들로서 구현될 수 있다. 이러한 실행가능 모듈들은 형식 안전성이 강제 적용되는 그리고 프로세스들이 그 자신의 별개의 메모리 객체들을 할당받는 관리 환경에서 실행되는 경우에 관리 코드일 수 있다. 이러한 실행가능 모듈들은 또한 C 또는 C++과 같은 네이티브 코드(native code)로 저작되는 실행가능 모듈들의 경우에 비관리 코드일 수 있다.

이하의 설명에서, 하나 이상의 컴퓨팅 시스템들에 의해 수행되는 동작들을 참조하여 실시예들이 기술된다. 이러한 동작들이 소프트웨어로 구현되는 경우, 동작을 수행하는 연관된 컴퓨팅 시스템의 하나 이상의 프로세서들은 컴퓨터 실행가능 명령어들을 실행한 것에 응답하여 컴퓨팅 시스템의 동작을 지시한다. 예를 들어, 이러한 컴퓨터 실행가능 명령어들은 컴퓨터 프로그램 제품을 형성하는 하나 이상의 컴퓨터 판독가능 매체 상에 구현될 수 있다. 이러한 동작의 일례는 데이터의 조작을 포함한다. 컴퓨터 실행가능 명령어들(및 조작된 데이터)는 컴퓨팅 시스템(100)의 메모리(104)에 저장될 수 있다. 컴퓨팅 시스템(100)은 또한 컴퓨팅 시스템(100)이, 예를 들어, 네트워크(110)를 통해 다른 프로세서들과 통신할 수 있게 하는 통신 채널들(108)을 포함할 수 있다.

본 명세서에 기술된 실시예들은, 예를 들어, 이하에서 더 상세히 논의되는 바와 같이, 하나 이상의 프로세서들 및 시스템 메모리와 같은 컴퓨터 하드웨어를 포함하는 특수 목적 또는 범용 컴퓨터를 포함하거나 이용할 수 있다. 본 명세서에 기술된 실시예들은 또한 컴퓨터 실행가능 명령어들 및/또는 데이터 구조들을 전달 또는 저장하는 물리적 및 기타 컴퓨터 판독가능 매체를 포함한다. 이러한 컴퓨터 판독가능 매체는 범용 또는 특수 목적 컴퓨터 시스템에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있다. 컴퓨터 실행가능 명령어들을 저장하는 컴퓨터 판독가능 매체는 물리적 저장 매체이다. 컴퓨터 실행가능 명령어들을 전달하는 컴퓨터 판독가능 매체는 전송 매체이다. 이와 같이, 제한이 아닌 예로서, 본 발명의 실시예들은 적어도 2 개의 뚜렷하게 상이한 종류의 컴퓨터 판독가능 매체 - 즉, 컴퓨터 저장 매체 및 전송 매체 - 를 포함할 수 있다.

컴퓨터 저장 매체는 컴퓨터 실행가능 명령어들 또는 데이터 구조들의 형태로 되어 있는 원하는 프로그램 코드 수단을 저장하는 데 사용될 수 있고 범용 또는 특수 목적 컴퓨터에 의해 액세스될 수 있는 RAM, ROM, EEPROM, CD-ROM 또는 기타 광 디스크 저장소, 자기 디스크 저장소 또는 기타 자기 저장 디바이스, 또는 임의의 다른 유형적 저장 매체를 포함한다.

"네트워크"는 컴퓨터 시스템들 및/또는 모듈들 및/또는 기타 전자 디바이스들 간의 전자 데이터의 전송을 가능하게 하는 하나 이상의 데이터 링크들로서 정의된다. 정보가 네트워크 또는 다른 통신 연결(유선, 무선 또는 유선 또는 무선의 조합)을 통해 컴퓨터로 전송되거나 제공될 때, 컴퓨터는 적절하게도 그 연결을 전송 매체로 본다. 전송 매체는 컴퓨터 실행가능 명령어들 또는 데이터 구조들의 형태로 되어 있는 원하는 프로그램 코드 수단을 전달하는 데 사용될 수 있고 범용 또는 특수 목적 컴퓨터에 의해 액세스될 수 있는 네트워크 및/또는 데이터 링크들을 포함할 수 있다. 상기한 것들의 조합들도 컴퓨터 판독가능 매체의 범주 내에 포함되어야 한다.

게다가, 다양한 컴퓨터 시스템 구성요소들에 도달할 때, 컴퓨터 실행가능 명령어들 또는 데이터 구조들의 형태로 되어 있는 프로그램 코드 수단이 전송 매체로부터 컴퓨터 저장 매체로(또는 그 반대로) 자동으로 전달될 수 있다. 예를 들어, 네트워크 또는 데이터 링크를 통해 수신되는 컴퓨터 실행가능 명령어들 또는 데이터 구조들이 네트워크 인터페이스 제어기(예컨대, "NIC") 내의 RAM에 버퍼링될 수 있고, 이어서 궁극적으로 컴퓨터 시스템 RAM으로 및/또는 컴퓨터 시스템에 있는 저휘발성(less volatile) 컴퓨터 저장 매체로 전달될 수 있다. 따라서, 컴퓨터 저장 매체가 또한(또는 심지어 주로) 전송 매체를 이용하는 컴퓨터 시스템 구성요소들에 포함될 수 있다는 것을 잘 알 것이다.

컴퓨터 실행가능 명령어들은, 프로세서에서 실행될 때, 예를 들어, 범용 컴퓨터, 특수 목적 컴퓨터, 또는 특수 목적 처리 디바이스로 하여금 특정의 기능 또는 일군의 기능들을 수행하게 하는 명령어들 및 데이터를 포함한다. 컴퓨터 실행가능 명령어들은, 예를 들어, 바이너리(binary), 어셈블리어와 같은 중간 포맷 명령어(intermediate format instruction), 또는 심지어 소스 코드일 수 있다. 발명 요지가 구조적 특징들 및/또는 방법 동작들과 관련하여 기술되어 있지만, 첨부된 청구범위에서 한정된 발명 요지가 상기한 기술된 특징들 또는 동작들로 꼭 제한되는 것은 아님을 잘 알 것이다. 오히려, 기술된 특징들 및 동작들은 청구항들을 구현하는 예시적인 형태들로서 개시되어 있다.

통상의 기술자라면 본 발명이 개인용 컴퓨터, 데스크톱 컴퓨터, 랩톱 컴퓨터, 메시지 프로세서, 핸드헬드 디바이스, 멀티프로세서 시스템, 마이크로프로세서 기반 또는 프로그램가능 가전 제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 이동 전화, PDA, 페이저, 라우터, 스위치 등을 비롯한 많은 유형의 컴퓨터 시스템 구성들을 갖는 네트워크 컴퓨팅 환경들에서 실시될 수 있다는 것을 잘 알 것이다. 본 발명은 또한 네트워크를 통해 (유선 데이터 링크, 무선 데이터 링크에 의해, 또는 유선 및 무선 데이터 링크들의 조합에 의해) 연결되어 있는 로컬 및 원격 컴퓨터 시스템들 둘 다가 작업들을 수행하는 분산 시스템 환경들에서 실시될 수 있다. 분산 시스템 환경에서, 프로그램 모듈들은 로컬 및 원격 메모리 저장 디바이스들 둘 다에 위치될 수 있다.

변경불가능 공유가능 무복사 벌크 데이터

무복사를 지원하기 위한 주된 과제는 시스템 내의 상이한 계층들 간의 복사 동작으로서 정의되는 종래의 시스템들에서의 I/O 인터페이스였다. read API(Application Program Interface)는 애플리케이션 버퍼를 입력으로서 받고 그를 어떤 데이터 소스로부터의 데이터로 채운다. 이와 유사하게, write API는 애플리케이션 버퍼를 받고 그의 내용을 어떤 데이터 타겟(data target)에 쓴다. read/write API의 의미는 버퍼 정렬(buffer alignment), 할당 공간(allocation space) 및 보존에 대한 완전한 자유를 애플리케이션에 부여한다. 이 간단한 모델은 그 모델이 불연속 버퍼들을 표현할 수 없거나 데이터 복사 동작의 횟수를 감소시킬 수 없다는 몇 가지 본질적인 한계를 가진다.

많은 운영 체제들이 파일 시스템 버퍼 캐시 내의 페이지들을 애플리케이션과 공유하고 읽기/쓰기 인터페이스와 연관된 복사 동작들을 피하는 메커니즘으로서 메모리 매핑된 파일(memory-mapped file)을 지원한다. 네트워크 트래픽의 속도를 높이기 위해 파일 메모리 매핑을 사용하여 파일 시스템 버퍼 캐시로부터 데이터를 직접 송신하기 위해 특수 API들이 네트워크 인터페이스에 추가되었다.

메모리 매핑된 파일 추상화는 버퍼들의 기본적인 정렬 및 스파스 레이아웃(sparse layout)을 숨기는 것을 지원하지 않으며, 애플리케이션이 가상 매핑 및 논리 데이터 뷰를 직접 처리하고 관리하는 것을 필요로 한다. 예를 들어, 오프셋 10에 있는 파일에 액세스하는 애플리케이션은 정확한 주소를 도출하기 위해 매핑 기반 가상 주소(mapping base virtual address)에 대해 포인터 산술 연산(pointer arithmetic)을 적용할 필요가 있다. 파일이 매핑되어 있는 동안 파일을 확장시키는 것은 애플리케이션이 그의 주소 공간에서 꼭 연속적이지 않을 수 있는 부가의 뷰를 관리하는 것을 필요로 하고, 교차 뷰 액세스(cross view access)는 애플리케이션에 의해 처리될 필요가 있다.

메모리 매핑된 파일을 통한 데이터 복사를 피하는 것은 다른 단점들이 있다. 메모리 매핑된 파일과 읽기/쓰기 동작 간의 의미 일관성(semantic consistency)을 보장하는 것은 I/O 시스템, 메모리 시스템 및 파일 시스템 간의 복잡한 조정을 필요로 한다. 메모리 매핑된 I/O(memory-mapped I/O)는 동기적 완료(synchronous completion)의 오버헤드를 부과하는데, 왜냐하면 파일 영역에 매핑되는 가상 주소에서의 페이지 폴트 미스(page-fault miss)가, 물리 메모리에서 페이지가 이용가능할 때까지, 스레드를 정지(stall)시키기 때문이다.

복사 동작의 부담을 숨기기 위해 COW(copy-on-write) 가상 메모리 기법들이 또한 사용되어 왔다. 이들 COW 기법들은 애플리케이션이 입력 버퍼를 즉각 수정하는 일이 드물다는 가정에 기초하여 애플리케이션에 별칭(alias)을 주고 캐시 페이지를 버퍼링한다. 이것은 파일 시스템에게 복사 없이 동일한 물리 페이지(physical page)를 캐싱할 기회를 준다. 어떤 작업 부하에 대해, 이러한 최적화는 특히 애플리케이션 스택(application stack)과 저장소 스택(storage stack)이 상이한 보호 영역(protection domain)에 있을 때 상당한 복잡성을 대가로 복사 동작을 회피할 수 있다. 가상 메모리 페이지 재매핑(virtual memory page-remapping)과 같은 다른 기법들은 애플리케이션 버퍼들이 적절히 정렬되어 있을 때 특정의 조건 하에서 네트워크 수신 경로에 대해 유용하다.

도 2는 변경불가능 버퍼를 제공하는 방법(200)의 플로우차트를 나타낸 것이다. 도 3a는 버퍼를 채우는 프로세스가 행해지는 환경(300A)을 나타낸 것이다. 도 3b는 채워진 버퍼가 변경불가능으로 되는 환경(300B)을 나타낸 것이다. 그에 따라, 도 2의 방법(200)이 이제부터 도 3a 및 도 3b를 자주 참조하면서 기술될 것이다. 환경(300A 및 300B)이 도 1의 컴퓨팅 시스템(100) 내에서 발생할 수 있지만, 꼭 그럴 필요는 없다. 환경(300A 및 300B)이 분산되어 있거나 단일의 컴퓨팅 시스템 상에 위치해 있을 수 있다.

버퍼를 채우기 위해 사용되어야 하는 소스 데이터가 먼저 획득측(acquiring) 컴퓨팅 엔티티에 의해 액세스된다[동작(210)]. 소스 데이터가 임의의 데이터일 수 있지만, 하나의 실시예에서, 소스 데이터는 생성하기 위해 상당한 컴퓨팅 리소스들을 필요로 하는 대량의 벌크 데이터를 포함한다. 이 설명에서 그리고 청구범위에서, "컴퓨팅 엔티티"는 컴퓨팅 시스템에서 데이터를 처리할 수 있는 임의의 컴포넌트, 모듈, 메서드, 함수, 프로세스, 프로세서, 또는 이들의 임의의 조합이다. 이러한 컴퓨팅 엔티티는 분산되어 있거나 단일의 컴퓨터 상에 존재할 수 있다.

획득측 컴퓨팅 엔티티가 소스 데이터의 전부 또는 일부를 생성할 수 있다[동작(211)]. 다른 대안으로서 또는 그에 부가하여, 획득측 컴퓨팅 엔티티가 소스 데이터의 전부 또는 일부를 데이터 소스로부터 획득할 수 있다[동작(212)]. 예를 들어, 도 3a를 참조하면, 획득측 컴퓨팅 엔티티(320)는 [화살표(301)로 나타낸 바와 같이] 소스 데이터(311)를 데이터 소스(310)로부터 획득한다. 데이터 소스는, 예를 들어, 네트워크, 또는 디스크와 같은 비휘발성 저장 디바이스일 수 있다.

획득측 컴퓨팅 엔티티는 또한 버퍼를 획득한다[동작(220)]. 이 버퍼 획득(220)은 소스 데이터의 획득[동작(210)]과 병렬로 도시되어 있는데, 왜냐하면 본 명세서에 기술된 원리들의 최광의의 측면이 어느 한 동작이 먼저 일어날 것을 필요로 하지 않기 때문이다. 그렇지만, 어떤 시스템들에서, 하나의 동작이 다른 동작보다 먼저 요구될 수 있고 그리고/또는 그들이 적어도 부분적으로 동시 다발적으로(concurrently) 행해질 수 있다. 도 3a를 참조하면, 획득측 컴퓨팅 엔티티가 나중에 버퍼(330)를 데이터로 채울 수 있는 한, 획득측 컴퓨팅 엔티티(320)는 버퍼(330)를 획득한다.

획득측 컴퓨팅 엔티티가 소스 데이터를 생성하든지, 소스 데이터를 데이터 소스로부터 수신하든지, 또는 둘 다를 하든지에 관계없이, 획득측 컴퓨팅 엔티티는 버퍼를 데이터로 채운다[동작(230)]. 예를 들어, 도 3a를 참조하면, 획득측 컴퓨팅 엔티티(320)는 [화살표(302)로 나타낸 바와 같이] 데이터(311)를 버퍼(330)에 채운다.

버퍼가 이어서 변경불가능으로 분류된다[동작(240)]. 도 3b는, 데이터(311)가 버퍼(330) 내에 보호되어 있는 것으로 도시된 것 - 버퍼(330)가 이제 변경불가능이라는 것을 추상적으로 나타내는 교차 해칭된 경계(331)를 갖는 것으로 도시되어 있음 - 을 제외하고는, 도 3a의 환경(300A)과 유사한 환경(300B)을 나타내고 있다. 이 분류는 변경불가능 버퍼[예컨대, 도 3b의 버퍼(330)] 내에 채워져 있는 데이터[예컨대, 데이터(311)]를 변경불가능 버퍼의 수명 동안 변경하지 못하도록 보호하고, 또한 변경불가능 버퍼를 변경불가능 버퍼의 수명 동안 그의 물리 주소가 변경되지 않도록 보호한다. 이 변경불가능 특성으로 인해, 변경불가능 데이터에 대한 액세스가 충돌의 위험 없이 임의의 수의 컴퓨팅 엔티티들에 제공될 수 있는데, 그 이유는 그 컴퓨팅 엔티티들 각각이 그 데이터를 관찰하기만 할 수 있기 때문이다.

(C 또는 C++와 같은) 네이티브 언어(native language) 환경에서, 이러한 변경불가능성은 프로세서를 메모리의 특정의 범위에 쓰지 못하도록 제한하기 위해 프로세서의 MMU(Memory Management Unit)에 쓰는 것에 의해 달성될 수 있다. 이것은 아주 부담이 클 수 있고, 메모리 액세스에 대한 제한은 그다지 세분화되어 있지 않아, 종종 비교적 큰 페이지 레벨에서 달성된다. 게다가, 이것은 부담이 큰 동작일 수 있고, 페이지 레벨보다 더 작은 입도(granularity)에 있는 상이한 레벨들로부터의 데이터를 숨기기 위해 복사가 수행되는 상황을 회피하지 않는다.

관리 환경[관리 런타임(managed runtime)을 포함하는 환경]에서, 메모리를 변경불가능으로서 선언하기 위해 그리고 변경불가능성을 강제 적용하기 위해 소프트웨어가 사용된다. 게다가, 메모리에 대한 새로운 포인터가 엔티티에 주어질 때 증가하고 메모리에 대한 포인터가 엔티티에 의해 더 이상 사용되고 있지 않을 때 감소되는 사용 횟수를 통해 메모리 버퍼의 수명이 유지될 수 있다. 사용 횟수가 0으로 복귀할 때, 버퍼는 도달가능하지 않고, 메모리 관리자에 의해 회수될 수 있다. 하나의 실시예에서, 커널은 상이한 엔티티들에 메모리에 액세스할 권한을 부여하고, 사용 횟수를 유지하는 반면 관리 런타임은 변경불가능 메모리에 대한 뷰를 제공하고, 변경불가능성을 강제 적용하며, 데이터에 대한 제약조건들을 제공한다. 관리 환경에 관한 부가 내용은 도 12와 관련하여 이하에 기술된다.

도 4는 변경불가능 버퍼를 사용하는 방법의 플로우차트를 나타낸 것이다. 먼저, 뷰 컴포넌트(view component)가 변경불가능 버퍼에 대한 유연한 뷰를 제공하고[동작(401)], 이어서 그 뷰를 적절한 경우 변경불가능 버퍼의 상이한 소비자들에게 제공한다[동작(402)]. 컴퓨팅 엔티티는 이어서 그 각자의 뷰를 통해서만 변경불가능 버퍼에 액세스할 수 있다[동작(403)]. 예를 들어, 도 5의 환경(500)을 참조하면, 제1 컴퓨팅 엔티티(501)는 [화살표(521)로 나타낸 바와 같이] 제1 뷰(511)를 통해 변경불가능 버퍼(330)에 액세스하고, 제2 컴퓨팅 엔티티(502)는 [화살표(522)로 나타낸 바와 같이] 제2 뷰(512)를 통해 변경불가능 버퍼(330)에 액세스한다. 생략부호(513)는 이것이 단지 이들 두 개의 컴퓨팅 엔티티(501 및 502) 이외의 것들에 대해 계속될 수 있다는 것을 나타낸다. 뷰(511 및 512)가 상이한 뷰일 수 있지만, 동일한 뷰일 수도 있다. 그에 관계없이, 뷰 컴포넌트(520)는 기본 변경불가능 버퍼(330)의 상이한 뷰를 제공할 수 있다. 이 설명에서, "제1" 및 "제2"라는 용어는 단지 하나의 항목을 다른 항목과 구별하기 위해 사용되고, 어떤 종류의 순서, 우선순위, 위치, 또는 중요도를 암시하지 않는다.

일부 실시예들에서, 변경불가능 버퍼로부터의 데이터를 소비하는 컴퓨팅 엔티티들이 보호 또는 프로세스 경계의 상이한 쪽에 있을 수 있다. 예를 들어, 도 5는 그 각자의 뷰(511 및 512)를 통해 데이터를 소비하는 컴퓨팅 엔티티(501 및 502)가 실제로 경계(530)에 의해 분리되어 있다는 것을 나타내고 있다. 예를 들어, 컴퓨팅 엔티티(501 및 502)는 별개의 프로세스일 수 있고, 이 경우에 경계(530)는 프로세스들 간의 경계를 나타낸다. 경계(530)는 또한 보호 경계일 수 있고, 이 경우에 복사 없이 한쪽이 다른 쪽에 직접 데이터를 제공할 수 없다. 예를 들어, 컴퓨팅 엔티티(501)는 운영 체제 내의 커널 컴포넌트일 수 있는 반면, 컴퓨팅 엔티티(502)는 애플리케이션 컴포넌트와 같은 사용자 모드 컴포넌트일 수 있다.

전형적으로, 데이터가 복사되지 않는 한, 프로세스 및 보호 경계들을 가로질러 데이터가 공유되지 않는다. 이러한 복사는 상당한 양의 컴퓨팅 리소스를 사용할 수 있고, 복사되는 데이터의 양이 아주 많은 경우 또는 데이터의 상이한 부분들이 이러한 경계들을 가로질러 빈번히 공유되어야 하는 경우에 특히 그렇다. 본 명세서에 기술된 원리들은 복사 없이 프로세스 및 보호 경계들을 가로질러 데이터를 공유하기 위한 편리하고 유연한 메커니즘을 제공한다. 이것은 그에 의해 운영 체제의 성능을 향상시킨다.

뷰 제공자(520)에 의해 제공되는 뷰가 세분화되어 있을 수 있다. 예를 들어, 변경불가능 버퍼로부터 읽혀질 변경불가능 데이터가 네트워크 데이터인 것으로 가정하자. 프로토콜 스택의 다양한 계층들 각각은 그 네트워크 데이터의 상이한 부분들에 관심이 있을 수 있다. 네트워크 레벨 컴포넌트(인터넷 프로토콜 컴포넌트 등)는 네트워크 레벨 헤더에 관심이 있을 수 있는 반면, 애플리케이션 레벨 컴포넌트는 단순히 원시 페이로드(raw payload)에 관심이 있을 수 있다. 이들 두 개의 계층 사이에 네트워크 데이터의 상이한 부분들에 관심이 있는 상이한 컴포넌트들이 있다.

본 명세서에 기술된 원리들은, 네트워크 데이터가 복사되는 것을 필요로 함이 없이, 이 네트워크 데이터의 처리에 효과적으로 적용될 수 있다. 예를 들어, 프로토콜 스택의 최하위 레벨은 네트워크 패킷 전체를 볼 수 있을 것이다. 그 최하위 레벨은 그 패킷의 가장 바깥쪽 헤더를 처리하고, 뷰 정의(view definition)를 프로토콜 스택에서의 그 다음 상위 레벨 컴포넌트에 반환할 수 있다. 뷰 정의는 가장 바깥쪽 패킷을 제외한 네트워크 패킷의 범위(scope) 전체를 정의한다. 이 제2 컴포넌트는 뷰 정의를 뷰 제공자(520)에게 제공하고, 뷰 제공자는 이 뷰를 제2 컴포넌트에 제공한다. 이와 같이, 최하위 컴포넌트는 패킷 전체를 보는 반면, 그 다음 컴포넌트는 가장 바깥쪽 헤더를 갖지 않는 동일한 패킷을 본다. 이것은 데이터를 전혀 복사함이 없이 행해졌다. 그 대신에, 데이터는 변경불가능 버퍼 내에 유지되었다. 이것은 최상위 애플리케이션 계층이 패킷의 페이로드만을 정의하는 뷰 정의를 제공받을 때까지 반복될 수 있다.

도 6은 하나의 컴퓨팅 엔티티로부터 그 다음 컴퓨팅 엔티티로 변경불가능 데이터를 전달하는 방법(600)의 플로우차트를 나타낸 것이다. 제1 컴퓨팅 엔티티는 뷰 정의에 액세스하고[동작(601)], 그 뷰 정의를 뷰 제공자에 제공한다[동작(602)]. 뷰 제공자는 이어서 그 뷰를 제1 컴퓨팅 엔티티에 제공한다[동작(603)]. 제1 컴퓨팅 엔티티가 그의 논리를 수행한 후에[동작(604)], 그는 이어서 다른 뷰 정의를 변경불가능 버퍼로부터의 데이터를 처리해야 하는 그 다음 컴퓨팅 엔티티에 제공한다[동작(605)] 그 다음 컴퓨팅 엔티티는 이어서 이 방법(600)을 반복할 수 있고, 따라서 이 프로세스는 시스템의 다수의 계층들을 통해 계속될 수 있다.

이상에서는 무복사 방식으로 버퍼/스트림을 소비하는 것을 기술하고 있지만, 앞서 기술된 원리들은 데이터 생성자(data producer)에 의한 버퍼 및 스트림의 생성에도 적용될 수 있다. 데이터 생성자의 경우에, 애플리케이션이 (개별적으로 할당되는) 그 자신의 버퍼들을 송신하거나 데이터 생성자에게 쓰기가능한 뷰(writable view)(Spans)를 그 자신의 내부 버퍼에 제공하도록 요청하는 유연성이 있다. 이것은 어쩌면 복사를 제거할 뿐만 아니라, 반쯤 채워진 버퍼를 송신할 필요가 없게 함으로써 버퍼 이용률을 향상시킨다.

무복사 데이터 스트리밍

운영 체제를 통한 벌크 데이터 이동은 종종 스트림 아키텍처를 사용하여 모델링된다. 스트림은 소스에 의해 생성된 데이터가 그의 목적지로 전달될 수 있게 하는, 데이터 소스와 데이터 소비자 사이의 논리적 통로를 나타낸다. 스트림은 전형적으로 생성자와 소비자 사이의 처리량 불일치를 수용하기 위해 버퍼링을 구현한다.

예를 들어, 도 7은 데이터의 스트림(711)이 스트림 소스(710)로부터 스트림 버퍼(720) 내로 제공되고[화살표(701)로 나타내어져 있음] 이어서 버퍼(720)로부터 스트림 소비자(730)로 제공되는[화살표(702)로 나타내어져 있음] 스트리밍 환경(700)을 나타낸 것이다. 환경(700)은 또한 흐름 제어를 수행하는 스트림 관리자(740)를 포함한다. 스트림 관리자(740)는 스트림 소비자(730)에 대해 만족할 만한 속도로 스트림 부분들이 버퍼(720)로부터 스트림 소비자(730)로 피드되게 한다[화살표(702)로 나타내어져 있음]. 게다가, 스트림 관리자(730)는, 스트림 버퍼(720) 내의 스트림 부분들의 양이 스트림 소비자(730)가 스트림 부분들이 떨어질 위험에 있을 정도로 적지 않도록 그리고 스트림 버퍼(720)의 불필요한 양의 메모리가 점유될 정도로 많지 않도록 하기 위해, 스트림보다 앞서 적절한 읽기를 수행한다[화살표(701)로 나타내어져 있음]. 스트림 관리자(740)는 또한, 스트림 부분이 소비되면 스트림 부분에 의해 점유된 메모리가 회수될 수 있도록, 스트림 부분들의 수명을 관리한다.

스트림은 종종 논리적으로 다수의 프로세스 및/또는 보호 경계들을 넘어간다. 예를 들어, 애플리케이션이 파일로부터 데이터를 읽을 때, 데이터는 종종 보호 모드 디바이스 드라이버(protected-mode device driver)의 제어 하에 있는 물리적 디스크로부터 읽혀진다. 데이터는 이어서 파일 시스템 계층을 통과하고, 이어서 최종적으로 애플리케이션 코드에 의해 이용가능하게 된다. 종종, 계층 교차(layer crossing)는 성능 및 전력 소비에 영향을 미치는 데이터 복사를 필요로 할 수 있다.

그렇지만, 앞서 기술된 무복사 변경불가능 버퍼의 원리들이 프로세스들 또는 보호 경계들을 가로질러 스트림 부분들을 복사할 필요가 없어지는 [스트림 버퍼(720)와 같은] 스트림 버퍼를 구성하는 데 사용될 수 있다.

구체적으로는, 스트림 내의 다수의 스트림 부분들 각각에 대해 (도 2 내지 도 6과 관련하여 기술된 것과 같은) 변경불가능 버퍼가 설정되는 것으로 가정하자. 게다가, 스트림 부분이 수신될 때마다, 단일의 스트림 부분을 포함하는 연관된 변경불가능 버퍼를 생성하기 위해 도 2의 방법 및 도 3a 및 도 3b의 프로세스가 수행되는 것으로 가정하자.

이러한 변경불가능 버퍼는, 도 5 및 도 6에서 일반적인 데이터와 관련하여 기술된 바와 같이, 데이터의 복사를 필요로 함이 없이, 스트림 부분들을 포함하는 임의의 데이터가 시스템의 상이한 계층들 및 컴포넌트들을 통해 지나갈 수 있게 하고, 각각이 데이터에 대한 그 자신의 특정 뷰를 가질 수 있게 한다. 스트림 버퍼(720)는, 그 경우에, 단순히 변경불가능 버퍼들 - 각각이 그 안에 데이터로서 들어 있는 대응하는 스트림 부분을 가짐 - 의 집합체일 것이다. 각각의 스트림 부분이 소비될 때, 대응하는 변경불가능 버퍼의 메모리가 회수될 수 있다. 이와 같이, 본 명세서에 기술된 원리들을 사용하여 무복사 데이터 스트리밍이 가능하다.

무복사 캐싱

캐싱은 임의의 운영 체제의 I/O 서브시스템의 중요한 측면이다. 데이터 액세스 패턴들이 클러스터링되는 경향이 있고 동일한 데이터가 종종 여러 번 검색된다는 사실을 이용함으로써, 대기시간이 감소되고 유효 처리량(effective throughput)이 증가된다. 종래의 캐싱은 직교 보존 및 교체(orthogonal retention and replacement) 정책으로 각각 독립적으로 관리되는 운영 체제의 다양한 계층들에 전용 메모리 풀을 가지는 것에 의해 행해진다. 캐시로부터의 데이터에 액세스하는 것은 종종 데이터를 캐시 버퍼로부터 애플리케이션 버퍼로 복사하는 것을 필요로 한다.

도 2 내지 도 6과 관련하여 앞서 기술된 원리들은 프로세스들 간에 그리고 보호 경계들을 가로질러 변경불가능 버퍼들의 공유를 가능하게 하지만 - 그를 통해서는 함수 호출들이 행해질 수 없음 -, 오히려 경계들을 가로지르는 통신을 위해 훨씬 더 부담이 큰 프로세스간 통신(inter-process communication) 또는 보호 경계 교차 통신(cross protection boundary communication)이 사용되어야만 한다.

이들 원리는 캐시를 구현하는 데 사용될 수 있다. DMA(Direct Memory Access) 동작들로부터 데이터가 흐를 때, 데이터는 [도 3a, 도 3b 및 도 5의 변경불가능 버퍼(330)와 같은] 변경불가능 버퍼로서 시스템에 유입된다. 변경불가능 버퍼가 새로운 데이터를 전달하기 위해 시스템 여기저기로 순환될 수 있고, 이와 동시에 나중의 재사용을 위해 캐시 내에 스냅숏(snapshot)될 수 있다. 데이터에 대한 나중의 요청이 있을 때, 동일한 변경불가능 버퍼가 캐시로부터 검색되어 재사용될 수 있다 - 모두가 결코 복사하는 일이 없거나 실제로 심지어 기본 데이터(underlying data)에 액세스하는 일이 없음 -. 이것은 상당한 효율 이득을 가져온다.

컴퓨팅 엔티티가 변경불가능 버퍼 내의 기본 데이터에 기초하는 캐시를 보유할 때, 컴퓨팅 엔티티는 변경불가능 버퍼 내의 기본 데이터에 대한 "강한" 참조(strong reference)를 가지며, 변경불가능 버퍼의 데이터에 액세스하기 위해 그 강한 참조를 사용할 수 있다. 참조를 수식하기 위해 "강한"이라는 용어를 사용하는 것은 단지 그 참조를 이하에서의 "소프트(soft)" 참조 및 "약한(weak)" 참조라고 지칭되는 것과 구별하기 위해 사용된다. 마찬가지로, 참조를 수식하기 위해 "약한" 및 "소프트"라는 용어를 사용하는 것은 단지 그 참조들을 서로 그리고 강한 참조와 구별하기 위해 사용된다.

임의의 엔티티가 캐시 내의 변경불가능 버퍼에 대한 강한 참조를 가지는 한, 변경불가능 버퍼 및 그의 데이터는 강한 참조를 가지는 각각의 엔티티에 대해 강한 참조의 적어도 지속기간 동안 계속 존재하도록 보장된다. 변경불가능 버퍼에 대한 "소프트" 참조는, 먼저 소프트 참조를 강한 참조로 변환시키지 않고는, 변경불가능 버퍼로부터의 데이터에 액세스하기 위해 사용될 수 없다. 데이터 액세스가 완료되면, 강한 참조가 소프트 참조로 변환될 수 있다.

소프트 참조가 한 형태의 메모리 관리 힌트(memory management hint)로서 사용될 수 있다. 임의의 컴퓨팅 엔티티에 의한 주어진 변경불가능 버퍼에 대한 소프트 참조만이 있고 시스템이 메모리가 부족하게 되는 경우, 시스템은 그 변경불가능 버퍼를 지원하는 메모리를 회수하기로 선택할 수 있다. 이것이 일어나는 경우, 소프트 참조를 강한 참조로 변환하려는 그 다음 시도는 실패할 것이다. 버퍼의 내용이 상실되고, 컴퓨팅 엔티티는 데이터 소스로부터 다른 변경불가능 버퍼의 내용을 재생성해야만 할 것이다.

이 소프트 참조는 시스템에서의 캐시의 크기를 조정하기 위해 높은 정확성을 요구하지 않고 캐시를 위해 가능한 한 많은 시스템 메모리를 사용하는 귀중한 방식이다. 예를 들어, 캐시는 그의 데이터의 많은 부분을 강한 참조가 아닌 소프트 참조로서 보유하기로 선택할 수 있다. 다른 프로세스의 메모리 사용이 이어서 시스템을 메모리 부족 상태(low memory state)로 몰고 갈 정도로 급격히 많아질 수 있다. 시스템은 그러면 신속히 반응하여, 어느 프로세스에 얼마만큼의 메모리를 줄지에 관해 어떤 선택도 할 필요 없이, 메모리를 이들 소프트 참조로부터 해제시킬 수 있다.

컴퓨팅 엔티티는 또한 주어진 변경불가능 버퍼에 대한 "약한" 참조를 보유할 수 있다. 소프트 참조에서와 같이, 변경불가능 버퍼 내의 데이터에 액세스할 수 있기 위해서는 약한 참조가 "강한" 참조로 변환되어야만 한다. 강한 참조가 또한 약한 참조로 변환될 수 있다. 약한 참조는 이들 버퍼에 대한 제2 형태의 메모리 관리를 제공한다. 이는 약한 참조를 보유하는 컴퓨팅 엔티티로 하여금 그 버퍼에 의해 사용되는 메모리를 책임지게 하는 일 없이 변경불가능 버퍼에 대한 잠재적 액세스를 유지하는 데 사용된다. 임의의 프로세스에 의한 주어진 변경불가능 버퍼에 대한 약한 참조만이 있는 경우, 기본 버퍼(underlying buffer)가 즉각 해제될 수 있다.

변경불가능 버퍼에 대한 약한 참조는 변경불가능 버퍼에 대한 강한 참조를 가지는 다른 프로세스로부터 변경불가능 버퍼에 대한 강한 참조를 검색하는 데 필요하게 될 프로세스간 통신 및 보호 경계 교차 통신의 부담을 완화시키기 위해 사용될 수 있다. 즉, 다른 컴퓨팅 엔티티(에컨대, 다른 프로세스)로부터 그 버퍼들을 검색하는 부담을 완화시키기 위해, 비록 그 버퍼들이 그 다른 컴퓨팅 엔티티에 의해 캐싱되어 있더라도, 하나의 컴퓨팅 엔티티(예컨대, 하나의 프로세스)에서 약한 참조의 캐시가 생성될 수 있을 것이다.

도 9는 제2 컴퓨팅 엔티티가 제1 컴퓨팅 엔티티에 의해 지원되는 캐시로부터 처음으로 읽는 방법(900)의 플로우차트를 나타낸 것이다. 도 10은 제2 컴퓨팅 엔티티가 제1 컴퓨팅 엔티티에 의해 지원되는 캐시로부터 차후에 읽는 방법(1000)의 플로우차트를 나타낸 것이다. 방법(900) 및 방법(1000)은, 함께, 제2 컴퓨팅 엔티티가 제1 컴퓨팅 엔티티에 의해 보유된 캐시에 기초하여 로컬 캐시를 구축할 수 있게 한다. 방법(900) 및 방법(1000)은 도 8의 환경과 관련하여 수행될 수 있고, 따라서 도 8을 자주 참조하여 기술될 것이다.

도 8의 환경(800)을 먼저 참조하면, 제1 컴퓨팅 엔티티(810)는 변경불가능 버퍼(801)에 의해 지원되는 데이터의 캐시(811)를 가진다. 제2 컴퓨팅 엔티티(820)도 또한 변경불가능 버퍼로부터 데이터를 획득해야 한다. 제2 컴퓨팅 엔티티(820)도 또한 변경불가능 버퍼(801)로부터 도출되는 데이터의 캐시(812)를 유지해야 한다. 그렇지만, 캐시(812)는 소멸되기 전에 제2 컴퓨팅 엔티티로부터의 해제 명령을 기다릴 수 없다는 의미에서 약한 캐시(weak cache)이다. 이와 같이, 제2 컴퓨팅 엔티티(820)는 그의 캐시(812)가 언제 해제되는지에 대해 제어하지 않는다.

제1 컴퓨팅 엔티티(810)와 제2 컴퓨팅 엔티티(820) 사이에 경계(830)(프로세서간 또는 보호 경계)가 있다. 하나의 예시적인 구현에서, 제1 컴퓨팅 엔티티가 파일 시스템이고, 제2 컴퓨팅 엔티티가 파일 시스템에 의해 제공되는 파일들을 서비스하고 그리고/또는 처리하는 웹 서버인 것으로 가정하자.

제1 컴퓨팅 엔티티가 캐시(예컨대, 파일 시스템의 경우에 파일 캐시)를 획득할 때, 제1 컴퓨팅 엔티티는 데이터에 대한 더 빠르고 더 로컬인 액세스(따라서, 용어 "캐시")를 획득하지만, 캐시를 지원하는 변경불가능 버퍼에 대한 강한 참조도 획득한다. 강한 참조는, 제1 컴퓨팅 엔티티가 강한 참조를 계속 보유하는 적어도 그 동안은(그리고 다른 엔티티들이 또한 변경불가능 버퍼에 대한 강한 참조들을 보유하는 경우 어쩌면 더 오랫 동안), 변경불가능 버퍼(및 그의 데이터)가 계속 존재할 것이라는 보장을 제공한다. 이 상태에서, 제2 컴퓨팅 엔티티[예컨대, 제2 컴퓨팅 엔티티(820)]가 처음으로 제1 컴퓨팅 엔티티[예컨대, 제1 컴퓨팅 엔티티(810)]에 의해 지원되는 캐시[예컨대, 캐시(811)]로부터 읽는 방법(900)을 나타내는 도 9의 설명에 들어간다.

제2 컴퓨팅 엔티티는 변경불가능 데이터에 대한 강한 참조를 획득하기 위해 제1 컴퓨팅 엔티티와 통신한다[동작(901)]. 이것은 프로세스간 또는 보호 경계 교차 통신이고, 따라서 부담이 큰 통신이다. 그렇지만, 이는 캐시를 지원하는 변경불가능 버퍼가 계속 존재하는 동안 요구되는 유일한 경계 교차 통신(cross boundary communication)일 수 있다. 예를 들어, 웹 서버가 캐시 내에 들어 있는 파일에 대한 제1 요청을 수신한 것으로 가정하자. 이 초기 요청은 웹 서버로 하여금 이 초기 통신을 수행하고 파일 시스템으로부터 변경불가능 버퍼에 대한 강한 참조를 획득하게 할 수 있다. 이 강한 참조를 사용하여, 제2 컴퓨팅 엔티티는 변경불가능 버퍼로부터 데이터를 읽을 수 있다[동작(902)]. 캐시로부터 데이터를 읽을 때 또는 그 후에, 제2 컴퓨팅 엔티티는 변경불가능 버퍼에 대한 강한 참조를 변경불가능 버퍼에 대한 약한 참조로 격하(demote)시킨다[동작(903)].

도 10은 제2 컴퓨팅 엔티티의 캐시가 데이터를 갖지 않는 경우 제2 컴퓨팅 엔티티가 차후에 제1 컴퓨팅 엔티티에 의해 지원되는 캐시로부터 읽는 방법(1000)의 플로우차트를 나타낸 것이다. 캐시에 대한 약한 참조가 여전히 존재하는 동안 캐시로부터 읽으라는 요청을 수신할 때[동작(1001)], 제2 컴퓨팅 엔티티는 변경불가능 버퍼가 여전히 존재하는지를 판정한다[결정 블록(1002)]. 변경불가능 버퍼가 여전히 존재하는 경우[결정 블록(1002)에서의 "예"], 제2 컴퓨팅 엔티티는 그의 약한 참조를 변경불가능 버퍼에 대한 강한 참조로 변환시키고[동작(1011)], 버퍼로부터 읽으며[동작(1012)][그리고 그 데이터를 로컬 캐시(812)에 로컬적으로 캐싱하며], 그 후에 강한 참조를 다시 약한 참조로 변환시킨다[동작(1013)]. 이것은 제1 컴퓨팅 엔티티와의 프로세스간 또는 보호 경계 교차 통신을 수행함이 없이 행해진다. 오히려, 제2 컴퓨팅 엔티티는 단지 변경불가능 버퍼에 대한 뷰를 획득하고, 변경불가능 버퍼로부터 읽는다.

변경불가능 버퍼가 여전히 존재하지 않는 경우[결정 블록(1002)에서의 "아니오"], 제1 컴퓨팅 엔티티와 프로세스간 또는 보호 경계 교차 통신이 수행됨으로써 제1 컴퓨팅 엔티티로 하여금 데이터를 재획득하게 하고 새로운 변경불가능 버퍼를 재생성하게 한다[동작(1021)]. 이어서, 방법(900)으로 돌아가서, 제2 컴퓨팅 엔티티는 이어서 새로운 변경불가능 버퍼에 대한 강한 참조를 획득하고[동작(901)], 버퍼로부터 읽을 수 있다[동작(902)].

이와 같이, 제2 컴퓨팅 엔티티는 제1 컴퓨팅 엔티티의 강한 캐시(strong cache)(제1 컴퓨팅 엔티티의 제어로 동작되고 있는 것)로부터 도출되는 약한 캐시(제2 컴퓨팅 엔티티가 약한 캐시를 사용하여 끝나기 전에 재구축될 필요가 있을 수 있는 것)를 갖는 것으로 보일 수 있다. 이 제2 "약한" 캐시를 다른 강한 캐시 상부에 구축하는 것은 지원 캐시에 대한 교체(또는 축출) 정책에 어떤 문제들을 야기한다. 축출은 더 빈번히 사용되는 데이터[즉, "핫" 데이터(hot data)]를 위한 공간을 만들기 위해 덜 사용되는 데이터[즉, "콜드" 데이터(cold data)]가 캐시로부터 제거(또는 축출)되는 메커니즘을 지칭한다. 축출은 특정의 데이터 항목이 액세스되는 빈도에 관한 통계에 기초한다. 약한 캐시(812) 및 강한 캐시(811)는 데이터에 대한 상이한 요청들을 본 이후로 캐시 부분들의 액세스의 빈도에 관한 별개의 통계를 가진다.

구체적으로는, 약한 캐시(812)는 지원 캐시(811)로 폴백(fall back)하기 전에 제2 컴퓨팅 엔티티(820)에 의한 요청에 대해 먼저 서비스하기 위해 사용될 것이다. 이 약한 캐시는 이와 같이 핫 데이터에 대한 초기 참조를 제외한 모든 것을 흡수하여, 지원 캐시(811)에 대해 그의 유용성을 숨길 것이다. 이와 같이, 지원 캐시(811)가 새로운 항목들에 대한 요청들을 수신할 때, 이것을 해소하지 않고, 지원 캐시는 약한 캐시(812)의 통계에 따른 "핫"한 데이터가 약한 캐시(812)에 의해 여전히 보존되고 있는 항목들을 교체하게 할 수 있다. 이 교체는 기본 버퍼에 대한 마지막 영속적 강한/소프트 참조를 제거하여, 약한 캐시에서의 약한 참조에 대응하는 버퍼를 해제시킬 수 있다. 그러면, 약한 캐시에 대한 그 항목에 대한 그 다음 요청이 실패할 것이다.

본 명세서에 기술된 실시예들에 따르면, 이 문제는 [약한 캐시(812)가 알고 있는] 핫 데이터의 유용성을 지원 캐시(811)에 전달하는 것에 의해 해소된다. 본 시스템은 제2 컴퓨팅 엔티티가 데이터에 대한 약한 참조를 데이터에 대한 강한 참조로 변환할 때의 부수 효과로서 이 메커니즘을 제공할 수 있다. 본 시스템은 기본 버퍼마다 이것이 일어나는 횟수를 카운트하고, 이 횟수를 버퍼 자체에 대한 메타데이터 속성으로서 노출시킨다. 지원 캐시는 이어서 이 값을 질의하고 임의의 두 개의 시점들 사이에 발생한 참조들의 수를 결정할 수 있다. 이 정보는 그 항목을 양 캐시에 남아 있도록 하기 위해 지원 캐시의 교체 알고리즘에 의해 사용될 수 있다.

도 11은 제1 컴퓨팅 엔티티(또는 지원 캐시)가 축출을 수행하는 방법(1100)의 플로우차트를 나타낸 것이다. 먼저, 지원 캐시는 축출을 위한 후보를 식별하기 위해 그 자신의 통계를 사용한다[동작(1101)]. 제1 지원 캐시는 이어서 그 식별된 후보가 있는지 약한 캐시의 제2 통계를 참조한다[동작(1102)]. 제2 통계가 식별된 후보의 더 빈번한 액세스를 나타내는 경우, 식별된 후보가 당분간 캐시 내에 유지될 수 있도록, 제2 통계를 참조한 후에, 식별된 후보에 관한 축출 결정이 이어서 행해진다[동작(1103)].

이들 처음 세 개의 개념들(즉, 변경불가능 공유가능 무복사 벌크 데이터, 무복사 데이터 스트리밍, 및 무복사 캐싱)이 관리 코드 시스템에서 뿐만 아니라 비관리 코드 시스템에서도 적용될 수 있다. 그렇지만, 관리 시스템(managed system)에 의해 제공되는 뷰가 비관리 시스템(unmanaged system)의 뷰보다 더 신속하게 생성되고 훨씬 더 세분화되어 만들어질 수 있기 때문에, 본 원리들이 관리 시스템에서 더 효과적으로 사용될 수 있다.

도 12는 예시적인 관리 코드 시스템(1200)을 나타낸 것이다. 관리 시스템(1200)은 관리 메모리(1201)를 포함한다. 관리 시스템(1200)은 각각이 엔티티-특유의 메모리에 대한 배타적 액세스를 가지는 다수의 관리 코드 컴포넌트들(1230)을 가진다. 예를 들어, 실행 중인 관리 코드 컴포넌트들(1230)은 7 개의 컴포넌트들(1231 내지 1237)을 포함하는 것으로 예시되어 있지만, 생략부호(1238)는 이 개수가 아주 유연하다는 것을 나타낸다. 예를 들어, 컴포넌트들(1231 내지 1237)은 프로세스일 수 있다.

7 개의 실행 중인 컴포넌트들(1231 내지 1237) 각각은 대응하는 엔티티-특유의 메모리(1211 내지 1217)를 가진다. 관리 컴포넌트(managed component)는 다른 엔티티-특유의 메모리의 엔티티-특유의 메모리에 액세스할 수 없다. 따라서, 대응하는 관리 컴포넌트만이 그 엔티티-특유의 메모리에 액세스할 수 있도록 엔티티-특유의 메모리 간에 격리 보호(isolation protection)가 있다. 예를 들어, 컴포넌트(1231)는 엔티티-특유의 메모리 부분(1211)에는 액세스하지만, 엔티티-특유의 메모리 부분들(1212 내지 1217)에는 액세스하지 않고; 컴포넌트(1232)는 엔티티-특유의 메모리 부분(1212)에는 액세스하지만, 엔티티-특유의 메모리 부분(1211) 또는 엔티티-특유의 메모리 부분들(1213 내지 1217)에는 액세스하지 않으며, 이하 마찬가지이다.

관리 코드 메모리(1210)는 또한 공유 메모리(1219)를 포함한다. 이 공유 메모리(1219)는 도 3a, 도 3b 및 도 5의 변경불가능 버퍼(330)의 일례이다. 그렇다 해도, 앞서 기술된 원리들이 관리 코드 시스템에 전혀 의존하지 않는다. 그렇지만, 본 명세서에 기술된 마지막 두 개의 개념들은 관리 환경으로 제한된다. 도 12의 몇 개의 추가적인 요소들은 이들 마지막 두 개의 개념(즉, 균일 메모리 액세스 및 형식이 안전한 형식 변환)과 관련하여 기술될 것이다.

균일 메모리 액세스

관리 언어 환경에서의 메모리는 어쩌면 아주 동적인 것이다. 객체들이 힙(heap) 외부에 할당되고, 가비지 컬렉터에 의해 관리된다. 도 12를 참조하면, 관리 시스템(1200)은 가비지 컬렉터(1221)를 포함한다. 추론(heuristics)에 기초하여, 가비지 컬렉터는 이전에 사용된 공간을 회수하기 위해 객체들을 서로 압축하는 것에 의해 정기적으로 힙의 유지 관리를 수행한다. 객체들을 서로 압축한다는 것은 객체의 메모리 주소가 본질적으로 불안정하여, 가비지 컬렉터에 의한 변경의 대상이 된다는 것을 암시한다. 가비지 컬렉터는 특정의 코드 생성 패턴들에 그리고 객체들을 애플리케이션 레벨 코드에 투명한 방식으로 이동시킬 수 있기 위해 운영 체제로부터의 지원에 의존한다.

운영 체제의 I/O 서브시스템은 시스템 메모리를 통해 대량의 데이터를 셔플링(shuffling)할 책임이 있다. 읽기를 하고 있을 때, 데이터는 전형적으로 외부 디바이스로부터 획득되고 프로세서와의 최소한의 상호작용으로 디바이스 자체에 의해 관리되는 DMA 동작을 통해 메모리에 넣어진다. 이와 유사하게, 데이터 쓰기를 하고 있을 때, DMA 메모리 동작들이 메모리의 내용을 자동으로 읽을 수 있다.

DMA 동작은 그 동작 동안 메모리의 내용이 위치 변경되는 것과 다툴 수 없다. 그렇게 하는 것은 프로세서와 디바이스들 간의 세분화된 조정을 필요로 할 것이고, 이는 성능 및 전력 효율에 상당히 영향을 미칠 것이다. 이 제약의 결과로서, 관리 운영 체제에서 DMA를 지원하는 두 가지 일반적인 옵션이 있다:

가비지 컬렉터에 명시된 객체들을 위치 변경하지 말라고 지시하기 위해 메모리의 영역들에 대해 특수 피닝(pinning) 동작들이 사용된다. 이것은 DMA 동작들이 실행되는 동안 DMA 동작들이 영향을 받는 메모리의 일관성있는 스냅숏을 볼 수 있게 한다.

DMA 동작들이 가비지 수집의 대상이 아닌 특수 메모리 영역들에서 일어난다.

제1 접근법은 가비지 컬렉터의 효율을 상당히 방해할 수 있는데, 그 이유는 메모리의 피닝된 영역들을 처리하는 것이 압축 프로세스(compaction process)를 복잡하게 하고 그의 효율을 감소시키기 때문이다. 제2 접근법은 그 문제를 회피하지만, 통상의 메모리 영역과 특수한 DMA에 친숙한 메모리 영역 간에 데이터를 전송하기 위해 특수 로직이 필요하기 때문에, 과도한 메모리 복사를 쉽게 야기할 수 있다.

통합 메모리 액세스 아키텍처는, 메모리가 통상의 관리 메모리이든 특수한 DMA에 친숙한 메모리 영역이든 간에, 메모리를 참조하는 체계적인 방법을 제공한다. 이것은 프로그래머가 완전히 안전한 방식으로 DMA에 친숙한 메모리 영역에서 직접 데이터를 조작하는 것을 가능하게 하여, 객체를 피닝할 필요성 및 통상의 메모리와 DMA에 친숙한 메모리 간에 복사할 필요성 둘 다를 회피한다.

관리 언어 환경에서, 벌크 데이터는 전형적으로 배열에 보유된다. 관리 언어 환경[예컨대, 관리 시스템(1200)]은 배열을 직접 이해하고, 개개의 배열 요소들에의 액세스를 가능하게 하며 프로그래머가 배열의 경계를 넘어설 수 없도록 보장한다. 언어 환경에 의해 관리되기 때문에, 배열은 관리 힙에 위치되도록 제약된다.

도 12의 관리 시스템(1200)에서, 변경불가능 버퍼(1219)가 관리 힙의 외부에 위치해 있고, 따라서 통상의 상황 하에서 관리 프로그램으로부터 직접 액세스가능하지 않을 것이다. I/O 메모리에 대한 읽기 및 쓰기는 보통 명시적 읽기 및 쓰기 동작을 갖는 종래의 I/O 패키지를 사용하여 행해질 것이고, 이는 관리 힙에서의 통상의 메모리와 I/O 메모리 간의 암시적 복사를 유발한다.

관리 시스템은 관리 코드 컴포넌트로부터 변경불가능 버퍼(1219)에 직접 액세스하는 메커니즘을 제공하는 추상화(본 명세서에서 "스팬"이라고 지칭됨)를 포함한다. 도 12를 참조하면, 관리 메모리 부분(1211)은 추상적으로 표현된 스팬 추상화(span abstraction)(1240)를 비롯한 각종의 객체들을 포함한다. 배열이 동작하는 방법과 아주 유사한 방식으로 I/O 버퍼의 임의의 영역에의 직접 액세스를 제공하기 위해 스팬이 안전하게 생성될 수 있다. 게다가, 스팬이 관리 메모리를 참조하도록 생성될 수 있다. 스팬의 상부에 구축된 소프트웨어 추상화는 따라서 스팬의 기본 메모리의 위치에 무관할 수 있다. 이것은 추상화가 관리 메모리[예컨대, 메모리 부분들(1211 내지 1218)] 또는 변경불가능 버퍼(1219) 상에서 동작하도록 자연스러운 방식으로 설계될 수 있게 하는 궁극적인 합성 구상을 제공한다.

스팬에 대한 기본 저장소와 상호작용하는 것에 의해 스팬들이 생성된다. 예를 들어, 변경불가능 버퍼(1219)는 스팬에 의해 직접 제어되는 변경불가능 버퍼를 참조하는 스팬들을 반환하기 위해 메서드 호출을 제공할 수 있다. 이와 유사하게, 배열은 배열 또는 배열의 부분들을 가리키는 스팬들을 반환하는 메서드를 제공한다. 스팬이 구체화되면, 스팬은 이리저리 전달되고 대체로 배열이 통상의 관리 언어에서 사용되는 것처럼 사용될 수 있다.

스팬에서의 특정의 미묘함은 기본 저장소의 수명 관리에 관한 것이다. 관리 프로그래밍 환경의 주된 이점들 중 하나는 가비지 컬렉터가 객체가 더 이상 참조되지 않고 그의 저장소가 재활용될 수 있는 때를 검출할 책임을 떠맡는다는 것이다. 이것은, 예를 들어, 배열이 더 이상 유용하지 않을 때 일어나는 것이다.

스팬의 기초를 이루는 메모리가 통상의 가비지 수집되는 힙의 외부에 있을 때, 메모리를 참조하는 생성된 스팬들이 메모리 버퍼 자체보다 오래 존속하지 않도록 그 메모리의 수명이 주의깊게 관리되어야만 한다. 이것은 기본 메모리에 대한 참조 카운터를 사용하는 것 또는 스팬 자체의 수명을 제한하는 것과 같은 다수의 방식으로 처리될 수 있다.

하나의 실시예에서, 스팬 객체는 그가 표현하는 메모리의 영역에 대한 특수 주석이 추가된 포인터(specially-annotated pointer)를 보유한다. 가비지 컬렉터는 이들 특수 포인터를 이해하고 특별 대우를 한다. 가비지 수집 동작 동안, 가비지 컬렉터가 특수 포인터를 만나는 경우, 가비지 컬렉터는 포인터가 보유하는 주소를 고려한다. 가비지 컬렉터가 포인터가 관리 힙의 외부를 가리키는 것으로 검출하는 경우, 가비지 컬렉터는 그 시점으로부터 이후로 포인터를 완전히 무시한다. 그 대신에, 포인터가 관리 힙의 내부를 가리키는 것으로 밝혀지는 경우, 가비지 컬렉터는 포인터를 관리 객체에 대한 참조로서 취급하고, 따라서 기본 객체가 위치 변경되는 만일의 경우에 포인터의 값을 자동으로 조절한다.

다른 스팬의 하위 영역을 나타내는 스팬이 생성될 수 있다. 이것은 스팬을 복사를 하는 일 없이 안전하고 부담이 적은 방식으로 보다 큰 메모리 영역으로부터 청크(chunk)를 잘라내는 아주 편리한 방법으로 만든다. 그 결과 얻어진 스팬이, 비록 다른 스팬의 메모리의 서브셋이라고 별칭되지만, 임의의 다른 스팬처럼 보인다.

형식이 안전한 형식 변환

관리 프로그래밍 언어의 주된 역할은 프로그램이 메모리 내의 아무런 주소나 가져와 그를 객체로서 조작하는 것을 방지하는 형식 안전성을 강제 적용하는 것이다. 예를 들어, 도 12의 관리 시스템(1200)은 형식 안전성을 보장하는 형식 시스템(1222)을 포함한다. 모든 객체들이 명시적으로 획득되고, 각각의 객체의 주소가 가비지 컬렉터[예컨대, 가비지 컬렉터(1221)]에 의해 확실하게 제어된다. 이러한 시스템에서, 가비지 컬렉터의 직접 제어 하에 있지 않는 메모리는 애플리케이션 코드에 의해 직접 사용될 수 없다. 그 대신에, 메모리는, 사용될 수 있기 전에, 결국 특수 메모리로부터 다시 가비지 컬렉터에 의해 제어되는 메모리로 복사될 필요가 있게 되어 버리며, 이는 비효율적이다.

데이터가 DMA 동작을 통해 시스템 내로 들어가고 시스템으로부터 나옴에 따라, DMA 디바이스에 의해 조작되는 데이터는 전형적으로 어떤 고유의 형상을 가진다. 예를 들어, DMA를 통해 데이터를 쓸 때, 가비지 수집되는 힙에서의 어떤 데이터 구조는 전형적으로 쓰여질 필요가 있는 데이터를 보유한다. 그 구조 내의 데이터를 DMA 동작을 위해 필요한 형상으로 변환(transcribe)하기 위해 "직렬화(serialization)" 단계가 이어서 사용된다. 이 직렬화 단계는 지루하고, 오류를 발생시킬 수 있으며, 비효율적이다. 직렬화 및 역직렬화(deserialization)는 보통 관리 프로그래밍 언어의 중요 부분이다.

스팬 추상화를 이용함으로써, 범용 모델은 프로그래머가 객체 지향 의미(object-oriented semantics)를 사용하여 DMA 메모리 영역과 직접 상호작용할 수 있게 한다. 특수 형식 변환 지원은 프로그래머가 DMA 메모리 영역을 객체로서 보고 따라서 자연스러운 방식으로 메모리를 직접 읽고 쓰는 것을 가능하게 하여, 효율을 극대화시키고, 정확성을 향상시키며, 프로그래머의 작업을 단순화시킨다. 이 모델은 단지 DMA 메모리를 넘어 확장되어, 통상의 가비지 수집되는 메모리에 대해서도 확장된 형식 변환 의미(extended type casting semantics)를 지원한다.

형식 안전성을 유지하기 위해, 임의의 형식들 간의 형식 변환을 허용하는 것은 가능하지도 바람직하지도 않다. 그 대신에, 이 확장된 형식 변환에 포함될 수 있는 허용된 형식들의 세트를 제약하는 특정의 규칙이 존재한다. 그렇지만, 이 규칙은 꽤 광범위하며, 결국 DMA 동작에 보통 포함되는 데이터의 종류에 대해 완벽하게 동작한다.

관리 프로그래밍 언어에서, 메모리가 할당될 때마다, 메모리는 주어진 형식을 배정받는다. 형식은 메모리 블록의 상이한 부분의 중요성(significance) 및 메모리 블록에 대해 수행될 수 있는 동작들을 결정한다. 메모리가 비활성으로 되고 가비지 수집 프로세스를 통해 재활용될 때까지 메모리 블록에 대해 형식이 변경될 수 없다. 항상, 언어 환경은 메모리 블록을 할당하고, 형식 지정(typing)하며, 재활용하는 책임을 지고 있다.

형식 변환은 어떤 메모리를 관리 환경이 알고 있는 것과 다른 형식으로 취급하는 기능이다. 형식 변환은 네이티브 프로그래밍 언어에서는 통상적인 것이지만, 관리 언어는 일반적으로 형식 변환을 제공하지 않는다. 그 대신에, 관리 환경은 한 형식의 값을 다른 형식으로 복사하는 것을 가능하게 하는 형식 변환 메커니즘(type conversion mechanism)을 제공한다. 예를 들어, 정수 값을 부동소수점 값으로 변환하는 것이 가능하다. 그렇지만, 이것은 항상 복사를 통해 행해진다 - 원래의 메모리 장소는 변경되지 않은 채로 있음 -.

본 명세서에 기술된 원리들에 따르면, 형식 변환은 관리 언어에 범용 기능(general-purpose facility)으로서 도입된다. 나중에 설명되는 바와 같이, 형식 안전성이 유지되도록 하기 위해 제한이 적용된다.

관리 운영 체제에서, I/O 동작을 위해 사용되는 메모리는 피닝된 객체 또는 I/O에 전용된 메모리 영역이어야만 한다. 이전에 언급한 바와 같이, 이동하지 못하도록 메모리에 피닝된 객체는 부담이 크고, 가비지 수집되는 환경에서 많은 문제들을 야기한다. 본 명세서에 기술된 원리들은 [도 3a, 도 3b 및 도 5의 변경불가능 버퍼(330)와 같은] 변경불가능 버퍼를 가장하여 전용 I/O 메모리를 사용한다.

I/O 메모리는 관리 메모리 서브시스템의 범위 밖에 있다. 관리 환경은 이 메모리의 형식을 제어하지 않고, 따라서 관리 프로그램으로부터 이 종류의 메모리에 직접 액세스하는 것이 가능하지 않다. 그 대신에, 이 메모리가 명시적 호출을 사용하여 읽혀지거나 쓰여질 수 있게 하기 위해 특수 연결 코드[또는 접착 코드(glue code)]가 통상적으로 사용될 것이다. 이들 I/O 버퍼 내의 임의의 종류의 구조적 데이터(structured data)에 액세스하는 것은 엄청나게 비효율적인 코드를 수반하거나, 데이터를 I/O 메모리로 그리고 I/O 메모리로부터 통상의 관리 메모리로 복사하는 것을 수반하며, 이 또한 비효율적이다.

네트워크 디바이스로부터 획득되는 변경불가능 버퍼를 생각해보자. 이 버퍼에, 네트워킹 프로토콜 정보를 보유하는 TCP 헤더가 있다. 기본적으로 TCP 헤더 내의 데이터가 관리 프로그래밍 언어에서 사용될 수 있는 두 가지 방식이 있다. 이하의 표는 이들 접근법 둘 다와 각각에 포함되는 단계들을 나타내고 있다.

종래의 관리 환경	형식 변환
버퍼에서의 TCP 헤더의 오프셋을 결정함	버퍼에서의 TCP 헤더의 오프셋을 결정함
TCP 헤더 내의 각각의 필드에 대해, ReadInt32 또는 ReadInt16과 같은 API를 통해 필드를 읽음. 필드를 로컬 임시 저장소에 저장함	변경불가능 버퍼의 적절한 섹션을 TCP 헤더 객체로 변환함
모든 필드들이 읽혀질 때, 관리 힙에 TCP 헤더 객체를 생성함. 이것은 또다시 TCP 헤더 내의 각각의 필더를 명시적으로 복사하는 것을 수반하고, 이 때는 로컬 저장소로부터 힙 저장소로 복사함.	무엇이든 필요한 동작을 수행하기 위해 TCP 헤더 객체에 액세스함
무엇이든 필요한 동작을 수행하기 위해 TCP 헤더 객체에 액세스함

사용가능한 TCP 헤더 객체를 획득하는 것은 종래의 접근법에서보다 형식 변환에서 상당히 더 빠르다. 새로운 접근법은 포인터 산술 연산(pointer math)이 가능하고 이 종류의 시나리오에서 빈번히 이용되는 네이티브 운영 체제에서 일어나는 것을 모방하고 있다. 포인터 산술 연산이 관리 프로그래밍 언어에서는 이용가능하지 않지만, 형식이 안전한 형식 변환이 동일한 기능을 제공한다.

더 많거나 더 적은 오버헤드를 야기하는, 종래의 접근법에 대한 변동들이 가능하다. 예를 들어, 문제의 메모리 버퍼가 프로그래머에게 직접 이용가능하고, 따라서 Read/Write 메서드를 사용하는 것보다 더 효율적으로 액세스될 수 있는 것이 가능하다. 그렇지만, 그 경우에, 프로그래머는 여전히 바이트들의 시퀀스를 상위 레벨 객체로 바꿀 책임이 있으며, 이는 지루하고, 오류를 발생시킬 수 있으며, 원만하게 이루어지지 않는다.

형식 변환을 가능하게 만들고 형식 안전성이 유지되도록 보장하는 것은 형식 변환이 그것을 허용하도록 설계되어 있는 형식들에 대해서만 가능하다는 것이다. 형식 변환에 참여하기 위해, 1) 형식들은 (참조 형식과 달리) 값 형식이고, 2) 형식들은 형식 변환을 지원하는 다른 형식들만으로 이루어져 있으며, 3) 형식들은 참조들로 이루어져 있지 않고, 4) 형식들은 특정의 메모리 레이아웃을 사용하여 정의되며, 5) 형식들은 그의 필드들 중 임의의 것에서 임의의 비트 패턴을 허용한다.

이들 제한은, 형식 변환에 사용되기 위해, 형식이 다른 객체들에 대한 참조를 포함할 수 없다는 것을 의미한다. 이들 제한이 TCP 헤더와 같은 데이터 포맷 및 다른 이러한 데이터 구조의 거대한 세트를 표현하도록 정의된 형식들의 특성을 완벽하게 기술하고 있는 것으로 밝혀졌다.

기술된 바와 같이, 형식이 안전한 형식 변환은 관리 메모리 환경의 범위 밖에 위치해 있는 I/O 버퍼를 읽고 그에 쓰기 위해 사용될 수 있고, 또한 관리 메모리를 다른 유형으로서 보기 위해 사용될 수 있다. 상세하게는, 이 기법은 바이트들의 배열을 그 대신에 하나 이상의 보다 풍부한 형식(rich type)들의 인스턴스로서 보는 데 유용하다.

도 13은 2 개의 별개의 스팬들이 그것을 포인팅하여 애플리케이션이 배열의 부분들을 상이한 형식들로서 볼 수 있게 하는 바이트들의 통상의 관리 배열을 나타낸 것이다. 임의의 수의 스팬들이, 각각이 별개의 형식을 갖도록, 이러한 방식으로 생성될 수 있다. 스팬들이 자유롭게 중복하여, 어쩌면 상이한 유형들과 동일한 메모리 영역을 참조할 수 있다.

임의의 비트 패턴이 그의 필드들 중 임의의 것에서 허용되어야만 한다고 되어 있는 규칙이 모델의 안정성에 중요하다. 형식 변환을 사용할 때, 그렇지 않았으면 정상적으로 보일 객체의 인스턴스가 형식 생성자(type constructor)를 실행함이 없이 환경에 유입된다. 통상적으로, 생성자는 입력 인수(input argument)들의 유효성 검사를 수행하고, 궁극적으로 객체를 이루고 있는 일련의 허용된 값들을 제약하는 역할을 한다. 그러나, 형식 변환에 의해, 기존의 메모리 스팬을 마치 상이한 형식인 것처럼 보는 것에 의해 객체를 느닷없이(out of thin air) 생성하는 것이 가능하다.

데이터를 관리 힙 내의 별개의 객체로 복사하는 종래의 접근법은 데이터를 유효성 검사할 기회를 제공하는데, 그 이유는 데이터가 관리 객체의 생성자 내로 푸시되기 때문이다. 이것은, 실세계 시스템에서, 관리 객체의 유효하지 않은 버전ㄴ들이 시스템 내에 결코 존재하지 않고, 생성자가 유효한 버전들만이 생성될 수 있도록 보장한다는 것을 의미한다. 이것을 임의의 비트 패턴이 나타날 수 있는 형식 변환과 대비해보자. 의미적으로 유효하지 않은 값들이 있는 경우, 객체 생성이 행해지지 않기 때문에 그들이 검출될 수 없다.

정확성 문제에 대한 해결책은 부가의 추상화 계층을 소프트웨어에 도입하는 것이다. 상세하게는, TCP 헤더를 읽는 것을 다시 예로 들면, 개발자가 다음과 같은 두 개의 별개의 형식들을 정의했다고 상상할 수 있다: RawTcpHeader 및 ValidTcpHeader.

입력 버퍼 내의 데이터는 RawTcpHeader로 변환된 형식일 것이다. 그 객체가 주어진 경우, AcquireValidTcpHeader 메서드가 호출될 수 있다. 이 메서드는 RawTcpHeader 내의 필터들을 유효성 검사할 것이고, RawTcpHeader 주위의 간이 래퍼(trivial wrapper)로서 역할할 ValidTcpHeader의 새로운 인스턴스를 반환할 것이며, 보유자에게 유효한 것으로 보장된 헤더를 가지고 있다고 알려줄 것이다. 이 모두는 복사 없이 행해지고, ValidTcpHeader 값 형식인 통과 객체(pass-through object)의 생성에 불과하다.

본 발명은 그의 사상 또는 본질적인 특성들을 벗어남이 없이 다른 구체적인 형태들로 구현될 수 있다. 기술된 실시예들이 모든 점에서 제한적이 아니라 단지 예시적인 것으로 간주되어야 한다. 따라서, 본 발명의 범주는 이상의 설명이 아니라 첨부된 청구범위에 의해 나타내어진다. 청구범위의 등가성의 의미 및 범주 내에 속하는 모든 변경들이 청구범위의 범주 내에 포함된다.

Claims (19)

1. 시스템에 있어서,
   각각이 관리 컴퓨팅 엔티티(managed computing entity)에 대응하는 복수의 관리 메모리 부분(managed memory portion)들을 가지는 관리 메모리;
   상기 관리 메모리의 외부에 위치해 있는 변경불가능 버퍼(immutable buffer)로서, 상기 복수의 관리 메모리 부분들 중 특정의 관리 메모리 부분은, 복수의 관리 컴퓨팅 엔티티들 중 대응하는 특정의 관리 컴퓨팅 엔티티에 액세스가능하지만 다른 관리 컴퓨팅 엔티티들에는 액세스가능하지 않은, 하나 이상의 가비지 수집가능 객체(garbage collectable object)를 포함하고, 상기 특정의 관리 메모리 부분은 또한 상기 변경불가능 버퍼에 대한 하나 이상의 참조를 포함하는 것인, 상기 변경불가능 버퍼; 및
   상기 특정의 관리 메모리 부분에 있는 상기 하나 이상의 가비지 수집가능 객체를 관리하도록 구성되지만, 또한 상기 변경불가능 버퍼에 대한 상기 하나 이상의 참조에 대해서는 어떤 동작도 수행하지 않도록 구성된 가비지 컬렉터(garbage collector)
   를 포함하는, 시스템.
2. 제1항에 있어서,
   상기 관리 메모리는 관리 힙(managed heap)인 것인, 시스템.
3. 제1항에 있어서,
   상기 변경불가능 버퍼는, 상기 변경불가능 버퍼의 수명 동안 자신의 데이터가 변경되는 것으로부터 보호되는 것인, 시스템.
4. 제3항에 있어서,
   상기 변경불가능 버퍼는, 상기 변경불가능 버퍼의 수명 동안 자신의 물리 주소(physical address)가 변경되는 것으로부터 보호되는 것인, 시스템.
5. 제1항에 있어서,
   상기 변경불가능 버퍼는, 상기 변경불가능 버퍼의 수명 동안 자신의 물리 주소가 변경되는 것으로부터 보호되는 것인, 시스템.
6. 제1항에 있어서,
   상기 하나 이상의 참조 중 적어도 하나는 배열 요소(array element)인 것인, 시스템.
7. 제6항에 있어서,
   상기 배열 요소는 상기 변경불가능 버퍼의 적어도 일부분의 주소를 포함하는 것인, 시스템.
8. 제1항에 있어서,
   상기 하나 이상의 참조 중 적어도 하나의 참조는 상기 변경불가능 버퍼의 적어도 일부분의 주소를 포함하는 것인, 시스템.
9. 제8항에 있어서,
   상기 가비지 컬렉터는, 상기 주소가 상기 관리 메모리의 외부에 해당함을 결정하도록 구성되는 것인, 시스템.
10. 제9항에 있어서,
    상기 주소가 상기 관리 메모리의 외부에 해당함을 상기 가비지 컬렉터가 결정할 때, 상기 가비지 컬렉터는 상기 하나 이상의 참조 중 상기 적어도 하나의 참조에 대해 가비지 수집을 수행하지 않는 것인, 시스템.
11. 제1항에 있어서,
    상기 특정의 관리 메모리 부분은 제1 관리 메모리 부분이고, 상기 특정의 관리 컴퓨팅 엔티티는 상기 복수의 관리 컴퓨팅 엔티티들 중 제1 컴퓨팅 엔티티이며,
    상기 복수의 관리 메모리 부분들 중 제2 관리 메모리 부분은 또한, 상기 복수의 관리 컴퓨팅 엔티티들 중 대응하는 제2 컴퓨팅 엔티티에 액세스가능하지만 상기 다른 관리 컴퓨팅 엔티티들에는 액세스가능하지 않은, 하나 이상의 가비지 수집가능 객체를 포함하고, 상기 제2 관리 메모리 부분은 또한 상기 변경불가능 버퍼에 대한 하나 이상의 참조를 포함하는 것인, 시스템.
12. 제11항에 있어서,
    상기 가비지 컬렉터는 또한, 상기 제2 관리 메모리 부분 내의 상기 하나 이상의 가비지 수집가능 객체를 관리하도록 구성되지만, 또한 상기 제2 관리 메모리 부분 내의 상기 변경불가능 버퍼에 대한 상기 하나 이상의 참조에 대해서는 어떤 동작도 수행하지 않도록 구성되는 것인, 시스템.
13. 가비지 수집을 수행하기 위한 방법에 있어서,
    특정의 컴퓨팅 엔티티에 대응하는 특정의 관리 메모리 부분을 검토하는 단계로서, 관리 메모리는 복수의 관리 메모리 부분들을 포함하고, 각각의 관리 메모리 부분은 컴퓨팅 엔티티에 대응하는 것인, 상기 검토하는 단계;
    상기 관리 메모리의 외부에 있는 변경불가능 버퍼에 대한 참조를 포함하는 상기 특정의 관리 메모리 부분을 검토할 때 복수의 객체들을 만나는(encounter) 단계;
    상기 참조를 만날 때, 상기 참조가 상기 관리 메모리의 외부에 있는 항목에 대응한다고 판정하는 단계; 및
    상기 판정하는 단계의 결과로서, 상기 참조에 대응하는 상기 항목에 대해 가비지 수집을 수행하지 않는 단계
    를 포함하는, 가비지 수집을 수행하기 위한 방법.
14. 제13항에 있어서,
    상기 참조는 배열 요소인 것인, 가비지 수집을 수행하기 위한 방법.
15. 제13항에 있어서,
    상기 항목은 상기 변경불가능 버퍼의 적어도 일부분인 것인, 가비지 수집을 수행하기 위한 방법.
16. 제13항에 있어서,
    상기 관리 메모리의 다른 관리 메모리 부분들은 또한, 상기 관리 메모리의 외부에 있는 상기 항목에 대한 참조를 포함하는 것인, 가비지 수집을 수행하기 위한 방법.
17. 제13항에 있어서,
    상기 관리 메모리 부분의 외부에 있는 항목들을 참조하지 않는 객체들에 대해 가비지 수집을 수행하는 단계를 더 포함하는, 가비지 수집을 수행하기 위한 방법.
18. 컴퓨팅 엔티티가 메모리에 액세스하기 위한 방법에 있어서,
    관리 메모리 부분에 액세스하는 단계 - 상기 관리 메모리 부분은, 상기 컴퓨팅 엔티티에 특유한 복수의 엔티티-특유 객체들을 포함하고, 복수의 컴퓨팅 엔티티들에 의해 공유되는 관리 메모리의 외부에 있는 변경불가능 버퍼에 대한 참조를 또한 포함하며, 상기 엔티티-특유 객체들은 가비지 컬렉터에 의한 가비지 수집의 대상이 됨 -; 및
    상기 변경불가능 버퍼에 액세스하기 위해 상기 참조 - 상기 참조는, 상기 가비지 컬렉터에 의한 가비지 수집의 대상이 되지 않도록 구조화됨 - 를 사용하는 단계
    를 포함하는, 컴퓨팅 엔티티가 메모리에 액세스하기 위한 방법.
19. 제18항에 있어서,
    상기 참조는, 상기 관리 메모리 부분의 외부에 있는 주소를 나열하는 배열 요소인 것인, 컴퓨팅 엔티티가 메모리에 액세스하기 위한 방법.

Images