클래식 Mac OS 메모리 관리

Classic Mac OS memory management
"About This Computer" Mac OS 9.1 창은 열려 있는 각 응용 프로그램의 메모리 소비량과 시스템 소프트웨어 자체를 보여준다.

역사적으로, 고전적인 맥 OS는 현대 시스템에서 선호되지 않는 메모리 관리의 형태를 사용했다.이러한 접근방식에 대한 비판은 맥 OS X로의 변경으로 해결된 주요 영역 중 하나이다.

매킨토시 엔지니어들의 원래 문제는 가상 메모리를 지원하지 않는 모토로라 68000 기반의 컴퓨터 하드웨어에서 기계가 장착된 128KB의 램을 어떻게 최적으로 사용할 것인가 하는 것이었다.[1]그 당시 기계는 한 번에 하나의 애플리케이션 프로그램만 실행할 수 있었고, 고정된 2차 스토리지가 없었기 때문에, 엔지니어들은 그러한 특정 제약조건에 잘 맞는 간단한 계획을 구현했다.그러한 설계 선택은 기계의 개발로 잘 확장되지 않아 프로그래머와 사용자 모두에게 다양한 어려움을 야기했다.

단편화

원래 엔지니어들의 주된 관심사는 단편화, 즉 메모리의 반복적인 할당과 할당 해제로 인해 메모리가 너무 작아서 사용할 수 없는 메모리의 작은 고립된 영역들이 많이 생기게 되는데, 총 여유 메모리는 메모리에 대한 특정 요청을 만족시키기에 충분할 수 있다.이를 해결하기 위해 애플 엔지니어들은 핸들을 무효화하지 않고 실제 데이터를 이동시킬 수 있는 메모리에 대한 참조인 다시 연결 가능한 핸들의 개념을 사용했다.애플의 계획은 간단했다 – 손잡이는 단순히 추가 포인터의 (접근 불가능한) 테이블로 들어가는 포인터였고, 이는 결국 데이터를 가리켰다.[2]메모리 요청에 메모리 압축이 필요한 경우 이 작업이 수행되고 마스터 포인터 블록이라고 하는 테이블이 업데이트되었다.기계 자체는 이 계획에 사용할 수 있는 두 가지 영역인 시스템 힙(OS에 사용됨)과 애플리케이션 힙을 메모리에 구현했다.[3]한 번에 한 응용 프로그램만 실행하면 시스템이 잘 작동했다.응용 프로그램이 종료될 때 전체 응용 프로그램 힙이 해체되었기 때문에 조각화가 최소화되었다.

메모리 관리 시스템에는 약점이 있었다. 시스템 아키텍처가 메모리 보호를 지원했다면 가능한 것처럼 시스템 힙이 잘못된 애플리케이션으로부터 보호되지 않았고, 이는 시스템 문제와 충돌의 원인이 되는 경우가 많았다.[4]또한 핸들 기반 접근방식은 프로그래밍 오류의 근원을 열어주기도 했는데, 여기서 그러한 상호연결 가능한 블록 내의 데이터에 대한 포인터는 메모리가 이동하게 할 수 있는 호출 전체에 걸쳐 유효하게 유지되도록 보장할 수 없었다.이것은 존재하는 거의 모든 시스템 API에 있어서 실제적인 문제였다.당시 시스템 소유 데이터 구조의 투명성 때문에 API는 이를 해결하기 위해 거의 할 수 없었다.따라서 프로그래머는 그러한 포인터를 작성하지 않거나, 최소한 API 호출 후 모든 핸들을 무시하여 매우 신중하게 관리하지 않을 책임이 있다.많은 프로그래머들이 일반적으로 이러한 접근법에 익숙하지 않았기 때문에, 초기 Mac 프로그램들은 종종 이로 인해 발생하는 결함으로 인해 어려움을 겪었다.[5]

Palm OS와 16비트 Windows는 메모리 관리를 위해 유사한 체계를 사용하지만 Palm과 Windows 버전은 프로그래머 오류를 더 어렵게 만든다.예를 들어, Mac OS에서 핸들을 포인터로 변환하기 위해 프로그램은 핸들을 직접 참조하기만 하지만 핸들이 잠기지 않으면 포인터가 빠르게 무효가 될 수 있다.손잡이 잠금 및 잠금 해제를 위한 호출은 균형을 이루지 못하며, 10번 호출은HLock단 한 번의 호출로 풀리다HUnlock.[6] Palm OS 및 Windows에서 핸들은 불투명 유형이므로 참조 해제되어야 함MemHandleLockPalm OS 또는Global/LocalLockWindows에서.Palm 또는 Windows 응용 프로그램이 핸들로 완료되면 호출MemHandleUnlock또는Global/LocalUnlock. Palm OS와 Windows는 블록에 대한 잠금 카운트를 유지한다; 세 번의 호출 후MemHandleLock블록은 3번 호출한 후에만 잠금 해제된다.MemHandleUnlock.

중첩된 잠금 및 잠금 해제 문제를 해결하는 것은 다양한 방법을 채택함으로써 간단할 수 있지만(지겹기는 하지만) 이러한 방법은 관련 코드 블록의 가독성을 침해하고 코더 부분에 대한 인식과 규율을 요구한다.

메모리 누수 및 오래된 참조 자료

또한 메모리 "누수"(할당 범위 내에서 할당 해제 실패)를 방지하고 출시 후 오래된 손잡이에 대한 참조(대개 하드 크래시를 초래함)를 피하기 위해 인식과 규율이 필요하다. 즉, 단일 태스크 시스템에서 실행 중이거나 다른 프로그램이 실행 중일 경우 잠재적으로 재앙이 발생할 수 있다.

스위처

메모리 용량이 512KB 이상인 Mac이 여러 애플리케이션을 한 번에 실행하는 방식이었던 스위처(Switchcher)의 등장으로 상황이 악화됐다.[7]이는 일회성 접근 방식이 매우 제한적이라는 것을 알게 된 사용자들에게 필요한 진전이었다.애플은 이제 기존 애플리케이션과의 호환성은 물론 메모리 관리 모델에 전념했기 때문에, 각 애플리케이션이 사용 가능한 RAM에서 자체 힙을 할당받는 방식을 채택하지 않을 수 없었다.[8]각 힙에 할당된 실제 RAM의 양은 프로그래머가 설정한 각 응용 프로그램의 메타데이터에 코딩된 값으로 설정되었다.때때로 이 값은 특정 종류의 작업에 충분하지 않았으므로 값 설정은 사용자에게 노출되어 사용자가 자신의 요구 사항에 맞게 힙 크기를 조정할 수 있도록 해야 했다."파워 유저"들 사이에서 인기가 있지만, 이러한 기술적 구현 세부사항의 노출은 맥 사용자 철학의 개념에 반하는 것이었다.사용자를 난해한 기술에 노출시키는 것 외에도, 대부분의 RAM을 나중에 사용하지 않더라도 할당된 RAM을 모두 잡을 수 있는 애플리케이션이 만들어지기 때문에 비효율적이었다.다른 애플리케이션은 메모리가 부족할 수 있지만, 다른 애플리케이션에서 "소유한" 여유 메모리를 활용할 수 없을 것이다.[3]

응용 프로그램이 자매 응용 프로그램의 힙을 유익하게 활용할 수는 없지만, 일반적으로 부주의로 헛소리 주소에 쓰는 방법으로 응용 프로그램을 파괴할 수 있다.실수로 텍스트나 이미지 조각이나 지정되지 않은 위치를 포인터로 취급하는 애플리케이션은 프로그램이 종료된 후에도 "루커"를 남기면서 다른 애플리케이션이나 OS의 코드나 데이터를 쉽게 덮어쓸 수 있다.그러한 문제들은 분석하고 고치기가 극도로 어려울 수 있다.

스위처는 System 4.2에서 MultiFinder로 진화하여 System 7에서 Process Manager가 되었고, 그 무렵에는 이 계획이 오랫동안 고착되었다.애플은 분명한 한계를 극복하기 위해 노력했다. 즉, 임시 메모리는 애플리케이션에서 짧은 기간 동안 힙 밖에 놓여 있는 무료 RAM을 "빌릴" 수 있는 것이었지만, 이것은 프로그래머들에게 인기가 없었기 때문에 대부분의 문제를 해결하는데 실패했다.애플의 System 7 Tune-up addon은 "최소" 메모리 크기와 "선호" 크기를 추가했다. 만약 선호하는 메모리 양을 사용할 수 없다면, 이 프로그램은 최소 공간에서, 아마도 기능이 축소되었을 것이다.이는 시스템 7.1로 시작하는 표준 OS에 통합되었지만, 여전히 근본 문제를 다루지 않았다.[9]

사용되지 않는 메모리 부분을 디스크에 페이징하여 더 많은 메모리를 사용할 수 있게 만든 가상 메모리 체계는 Connectix Virtual과 같은 타사 유틸리티에 의해, 그리고 나서 Apple이 시스템 7에서 사용할 수 있게 되었다.이로 인해 성능 비용으로 Macintosh 메모리 용량이 증가했지만 보호된 메모리를 추가하거나 일부 포인터를 무효화할 메모리 관리자의 힙 압축을 방지하지는 못했다.

32비트 클린

원래 매킨토시는 128KB의 RAM을 가지고 있었고, 512KB의 한도를 가지고 있었다.이것은 매킨토시 플러스의 도입으로 4MB로 늘어났다.이들 매킨토시 컴퓨터는 32비트 프로세서인 68000 CPU를 사용했지만 24개의 물리적 주소 라인에 불과했다.24줄로 프로세서가 최대 16MB의 메모리(2바이트24)를 처리할 수 있게 해 당시 충분한 양으로 보였다.Macintosh 디자인의 램 한계는 메모리 맵의 구조 때문에 RAM 4MB와 ROM 4MB로 제한되었다.[10]이는 Macintosh II와 Macintosh Portable로 메모리 맵을 변경하여 최대 8MB의 RAM을 허용함으로써 수정되었다.

메모리는 부족한 자원이었기 때문에, Mac OS의 저자들은 각 주소에서 사용되지 않는 바이트를 이용하기로 결정했다.원래의 메모리 관리자(시스템 7이 등장할 때까지)는 각 32비트 포인터와 핸들의 높은 8비트에 플래그를 배치했다.각 주소에는 마스터 포인터 테이블에 저장된 "잠금", "구입 가능" 또는 "리소스"와 같은 플래그가 포함되어 있었다.실제 주소로 사용될 때, 이러한 플래그는 CPU에 의해 가려져 무시되었다.[4]

매우 제한된 RAM 공간을 잘 사용했지만, 이 디자인은 애플이 32비트 Motorola 68020 CPU를 사용한 Macintosh II를 도입하면서 문제를 일으켰다.68020에는 최대 4GB(2바이트32)의 메모리를 처리할 수 있는 32개의 물리적 주소 라인이 있었다.메모리 관리자가 각 포인터와 핸들의 높은 바이트에 저장한 플래그는 현재 유의했으며, 오류 해결을 유도할 수 있다.

이론적으로, 매킨토시 시스템 소프트웨어의 설계자들은 이 문제를 피하기 위해 "높은 바이트의 플래그" 체계를 자유롭게 변경할 수 있었고, 그들은 그렇게 했다.예를 들어, Macintosh IIci 이상 컴퓨터에서는HLock()그리고 다른 API는 높은 손잡이 비트에 플래그를 지정하는 것 이외의 방식으로 핸들 잠금을 구현하기 위해 다시 작성되었다.그러나 많은 Macintosh 애플리케이션 프로그래머와 많은 Macintosh 시스템 소프트웨어 코드 자체는 API를 사용하기 보다는 플래그에 직접 접근했다.HLock()그것은 그들을 조종하기 위해 제공되었다.이를 통해 그들은 응용 프로그램이 진정한 32비트 주소 지정과 호환되지 않게 되었고, 이것은 "32비트 클린"이 아닌 것으로 알려지게 되었다.

이 문제로 인한 지속적인 시스템 충돌을 막기 위해 68020 또는 68030에서 작동하는 시스템 6 이하에서는 기계를 24비트 모드로 강제 전환하고 하드웨어가 최대 128MB RAM을 수용하도록 배선된 기계의 명백한 결함인 첫 번째 8MB RAM만 인식 및 해결하며, 누구의 제품 문헌이 이를 광고했는가?능력시스템 7을 통해 마침내 Mac 시스템 소프트웨어가 32비트 청결하게 만들어졌지만, 여전히 더러운 ROM의 문제가 있었다.문제는 24비트 또는 32비트 주소 지정을 사용하는 결정은 부팅 프로세스 초기에 이루어져야 하는데, 이때 ROM 루틴이 메모리 관리자를 초기화하여 NuBus ROM과 디스크 드라이버가 로드되고 실행되는 기본 Mac 환경을 설정한다는 것이었다.구형 ROM은 32비트 Memory Manager를 지원하지 않아 32비트 모드로 부팅할 수 없었다.놀랍게도 이 결함의 첫 번째 해결책은 소프트웨어 유틸리티 회사 Connectix에 의해 발표되었는데, 1991년 제품 MODE32는 Memory Manager를 재초기화하고 Mac 부팅 프로세스의 초기 부분을 반복하여 시스템을 32비트 모드로 부팅할 수 있게 했으며 기계에 있는 모든 RAM을 사용할 수 있게 했다.애플은 1991년 이후 커넥텍스에서 이 소프트웨어를 라이선스하고 무료로 배포했다.매킨토시 IICI와 이후 모토로라 기반의 매킨토시 컴퓨터는 32비트의 깨끗한 ROM을 가지고 있었다.

24비트 종속성을 모두 제거하도록 애플리케이션이 업데이트되기까지는 꽤 오랜 시간이 걸렸고, 시스템 7은 애플리케이션 비호환성이 발견될 경우 24비트 모드로 다시 전환할 수 있는 방법을 제공했다.[3]PowerPC와 System 7.1.2로 마이그레이션할 무렵에는 기본 애플리케이션을 생성하기 위해 32비트 청결상태가 의무화되었으며, 이후 Motorola 68040 기반 Macs는 24비트 모드를 지원할 수 없었다.[6][11]

객체 방향

Mac 프로그래밍을 위한 객체 지향 언어(첫 번째 Object Pascal, 그 다음 C++)의 증가도 채택된 메모리 모델에 문제를 일으켰다.처음에, 물체가 다시 연결될 수 있다는 이점을 얻기 위해 손잡이를 통해 구현되는 것은 당연해 보일 것이다.이들 언어는 원래 고안된 대로 객체에 포인터를 사용했고, 이는 단편화 문제로 이어질 것이다.THINK (Later Symantec) 컴파일러에 의해 구현된 솔루션은 객체에 대해 내부적으로 Handles를 사용하되, 포인터 구문을 사용하여 해당 객체에 액세스하는 것이었다.이것은 처음에는 좋은 생각처럼 보였지만, 곧 프로그래머들이 다시 접속할 수 있는 블록을 다루고 있는지 고정된 블록을 다루고 있는지 알 수 없고, 그래서 물체를 잠그는 일을 맡아야 할지 말아야 할지 알 길이 없었기 때문에 깊은 문제가 나타났다.말할 필요도 없이 이것은 엄청난 수의 버그와 이러한 초기 객체 구현의 문제로 이어졌다.이후 컴파일러들은 이것을 시도하지 않고 실제 포인터를 사용했으며, 종종 Mac OS 메모리 모델에서 작동하기 위해 그들 자신의 메모리 할당 체계를 구현했다.

모든 고유한 문제가 있는 Mac OS 메모리 모델은 심각한 애플리케이션 호환성 제약으로 인해 Mac OS 9까지 바로 이러한 방식으로 유지되었지만, 저렴한 RAM의 가용성이 증가함에 따라 대부분의 사용자들이 코너에서 벗어나 업그레이드 할 수 있게 되었다.메모리는 효율적으로 사용되지 않았지만 문제가 결코 중대해지지 않을 정도로 풍부했다.이것은 매우 제한된 양의 메모리를 최대한 사용하는 것이 원래 디자인의 목적이었다는 것을 고려하면 아이러니하다.맥 OS X는 마침내 현대적인 희박한 가상 메모리 체계를 구현하면서 전체 체계를 없앴다.이전 메모리 모델 API의 하위 집합은 Carbon의 일부로서 호환성을 위해 여전히 존재하지만, 아래의 최신 메모리 관리자(스레드 세이프 구현)에 매핑된다.[6]Apple은 Mac OS X 코드 사용을 권장한다.malloc그리고free"독점적인"[12]

참조

  1. ^ Hertzfeld, Andy (September 1983), The Original Macintosh: We're Not Hackers!, retrieved May 10, 2010
  2. ^ Hertzfeld, Andy (January 1982), The Original Macintosh: Hungarian, archived from the original on June 19, 2010, retrieved May 10, 2010
  3. ^ a b c memorymanagement.org (December 15, 2000), Memory management in Mac OS, archived from the original on May 16, 2010, retrieved May 10, 2010
  4. ^ a b Hertzfeld, Andy, The Original Macintosh: Mea Culpa, retrieved May 10, 2010
  5. ^ Apple Computer (October 1, 1985), Technical Note OV09: Debugging With PurgeMem and CompactMem, retrieved May 10, 2010
  6. ^ a b c Legacy Memory Manager Reference, Apple Inc., June 27, 2007, retrieved May 10, 2010
  7. ^ Hertzfeld, Andy (October 1984), The Original Macintosh: Switcher, retrieved May 10, 2010
  8. ^ Mindfire Solutions (March 6, 2002), Memory Management in Mac OS (PDF), p. 2, retrieved May 10, 2010
  9. ^ "System 7.1 upgrade guide" (PDF). Archived from the original (PDF) on March 4, 2016. Retrieved May 26, 2015.
  10. ^ "memory maps". Osdata.com. March 28, 2001. Retrieved May 11, 2010.
  11. ^ Apple Computer (January 1, 1991), Technical Note ME13: Memory Manager Compatibility, retrieved May 10, 2010
  12. ^ Memory Allocation Recommendations on OS X, Apple Inc, July 12, 2005, retrieved September 22, 2009

외부 링크