스택 + 힙 + 정적 메모리 모델에 대한 대안이 있습니까?

내가 본 모든 프로그램은 데이터 메모리를 하나 이상의 호출 스택 (보통 고정 된 크기이지만 때로는 그렇지 않은 경우), 힙 및 정적 메모리로 구성합니다. 최근 스레드 로컬 정적 스토리지도 여기에 추가되었습니다.

호출 스택없이 데이터 메모리 레이아웃을 완전히 다른 방식으로 구성하려는 시도가 있었습니까? 아니면 같은 것을 성취하는 다른 방식으로 기억을 조직합니까?

뒤로 물러나서 기존 모델의 위치와 이유를 확인할 수 있습니다. 프로세스가 생성되면 단순히 0에서 N으로 색인되는 평평한 저장 영역이 제공됩니다.이 저장 영역 (여기서 RAM에 대해 이야기)은 전용 하드웨어와 일부 고급 반도체에 의해 지원되므로 매우 빠릅니다. 그러나 그 종류의 유일한 것은 아닙니다. 하드 드라이브와 같은 다른 장치는 기본적으로 인덱스로 주소를 지정할 수있는 동일한 공간이지만 크기는 훨씬 느립니다.

"힙"이 존재하는 이유는 각 응용 프로그램이 자체적으로 RAM 사용을 관리하려고 시도하는 것이 실용적이지 않기 때문입니다. 그 당시에는 프로그래머가 각 RAM 위치를 정확히 사용할 계획을 미리 계획했습니다. 소프트웨어가 더 복잡 해짐에 따라 누군가 블랙 박스로 가서 "10 바이트가 필요해"라고 말하면 10 바이트의 위치와 방법에 대한 모든 복잡한 세부 사항에 대해 걱정할 필요가 없습니다. 또는 그들이 어떻게 되 찾을 수 있는지. 그것은 힙이 무엇인지, 그보다 더 기본적이지는 않습니다.

스레드가 생성 될 때마다 방금 설명한 동일한 "gimme operation"을 사용하여 얻은 일부 데이터 구조 (및 스택)가 있습니다. 함수 호출 스택 프레임과 LIFO 특성에 완벽하게 맞기 때문에 거의 보편적으로 사용되는 스택입니다. 이론적으로 각 함수 호출 및 로컬 변수는 힙에 할당 될 수 있지만 스택 포인터 (x86의 ESP) 레지스터를 업데이트하는 데 필요한 몇 가지 어셈블리 명령에 비해 너무 비쌉니다.

TLS (Thread Local Storage)도 힙 위에 구축됩니다. 관리 구조에 메모리를 할당하기 위해 힙으로의 트립의 일부로 스레드가 작성되면 TLS를위한 별도의 공간도 힙에서 할당됩니다.

결국, 실제로 가지고있는 것은 일반적인 메모리 할당 자 (즉 힙)이며 다른 모든 것들은 그 위에 특수한 형태입니다. 다시 말해서, 만약 당신이 "원하는만큼 얼마든지 (또는 적은) 배분하고 싶을 때, 내가 원할 때까지 계속 유지하고 싶다"는 어떤 측면을 기꺼이 포기하고 싶다면, 당신은 거래를 멀리 할 수 ​​있습니다 속도를 제공하지만 다른 제한이있는 다른 모델에 대해서는 일반 힙 할당자를 사용하지 마십시오.

쌓아 라. 힙과 비교하면 엄청나게 빠르지 만 두 가지 단점은 1) 메모리가 해제되는 시점을 제어하지 않는 것입니다. 대신 함수가 종료되면 할당 된 내용이 사라지고 2) 스택의 크기가 일반적으로 제한되므로 대량의 데이터를 스택에 직접 할당하는 데주의해야합니다.

또 다른 유형의 "메모리 모델"은 시스템 호출을 통해 거의 모든 주요 OS에서 제공하는 VMM (Virtual Memory Manager)입니다. VMM은 많은 양의 메모리를 요청하고 원하는 기간 동안 유지할 수 있다는 점에서 힙과 매우 유사합니다. 그러나 페이지 크기 배수 (예 : 4KB)로만 메모리를 할당 할 수 있으므로 VMM을 직접 사용하면 일반적인 응용 프로그램에서 종종 한 번에 8-24 바이트를 할당하는 많은 오버 헤드가 발생할 수 있습니다. 실제로, 거의 모든 힙 구현은 매우 일반적이고 특수화되지 않은 작은 블록 할당 을 허용하기 위해 VMM을 기반으로 구축됩니다 . 힙은 더 많은 메모리가 필요할 때마다 VMM으로 이동 한 다음 해당 메모리의 많은 작은 청크를 애플리케이션에 할당합니다.

큰 블록을 할당해야하는 앱이있는 경우 malloc () 내부에 if 문이 있고 일부 블록 크기가 임계 값보다 크더라도 VMM으로 직접 이동하는 것을 고려할 수 있습니다. 당신을 위해.

힙을 직접 사용하는 대신 할당 기의 다른 형태는 풀입니다. 풀은 모든 블록의 크기가 같은 특수 할당 자입니다. 풀 (스택 및 TLS와 마찬가지로)은 힙 또는 VMM 위에 구축됩니다. 풀은 같은 크기의 단 수명 개체를 많이 (수백만) 할당하는 장소에 유용합니다. 들어오는 요청을 처리하는 네트워크 서비스를 생각하십시오. 각 클라이언트 요청으로 인해 해당 요청을 처리하기 위해 동일한 N 바이트 구조가 할당 될 수 있습니다. 풀 사용의 단점은 각 풀이 하나의 블록 크기 만 처리한다는 것입니다 (그러나 여러 풀을 만들 수는 있음). 풀의 장점은 모든 객체의 크기가 동일하기 때문에 복잡한 논리가 필요하지 않다는 것입니다. 대신 새 블록이 필요할 때마다 최근에 해제 된 블록 만 제공합니다.

그리고 마지막으로, 내가 언급 한 하드 드라이브가 맨 위에 있다는 것을 기억하십시오. 파일 시스템처럼 작동하고 디렉토리 항목 및 i- 노드와 동일한 아이디어를 복제하여 경로로 주소가 지정된 각 데이터 블록이있는 데이터 블록을 계층 적으로 할당 할 수있는 메모리 모델을 가질 수 있습니다. 바로 tmpfs가하는 일 입니다.

내가 언급 한 것 외에도 다른 더 전문화 된 모델이 있다고 확신하지만 결국 모든 것이 평평한 주소 공간을 기반으로하기 때문에 (일부는 일부 이상한 비 평평한 공간이 생길 때까지) ), VMM 또는 힙인 일반 "gimme"할당 자로 돌아갑니다.

내가 생각할 수있는 유일한 경우는 메모리의 고정 위치에서 모든 것이 실행될 수있는 특수 하드웨어입니다. 완전히 유연한 프로그램을 원한다면 현재 메모리 모델의 거의 모든 것이 필요합니다.

스택이 없으면 로컬 변수, 호출 스택 등을 가질 수 없습니다. 구현하기 위해 작성하는 다른 것은 스택과 매우 비슷하게 보일 것입니다.

정적 메모리 및 특정 응용 프로그램에 대해 잠재적으로 떨어질 수있는 힙이지만 다시 고급 형식을 수행하려면 특정 형식 또는 다른 형식으로 다시 필요합니다.

이 세 가지 중 하나를 대체하기 위해 발명 한 것은 결국이 세 가지 중 하나와 비슷하게 보일 것입니다.

다른 각도에서 접근하려면 새로운 것을 추가 할 수 있습니까? 그래픽 / 물리 프로세서 / cpu 캐시와 같은 것들이 새로운 메모리 위치라고 주장 할 수 있지만 실제로는 그것들은 별도의 인스턴스이거나 기존 모델에 대한 액세스 속도를 높이는 방법 일뿐입니다.

... 누군가가 일종의 거대한 개념적 도약을 할 때까지 나는 우리가이 분야에서 오랫동안 큰 변화를 볼 것 같지 않다고 생각합니다 ...