KR101976221B1 - 수정되지 않은 애플리케이션을 위한 메모리 관리 모델 및 인터페이스 - Google Patents

수정되지 않은 애플리케이션을 위한 메모리 관리 모델 및 인터페이스 Download PDF

Info

Publication number
KR101976221B1
KR101976221B1 KR1020137033920A KR20137033920A KR101976221B1 KR 101976221 B1 KR101976221 B1 KR 101976221B1 KR 1020137033920 A KR1020137033920 A KR 1020137033920A KR 20137033920 A KR20137033920 A KR 20137033920A KR 101976221 B1 KR101976221 B1 KR 101976221B1
Authority
KR
South Korea
Prior art keywords
memory
application
allocation
host
information
Prior art date
Application number
KR1020137033920A
Other languages
English (en)
Other versions
KR20140033448A (ko
Inventor
제레미아 씨 스프라들린
갈렌 헌트
애닐 에프 토마스
스티븐 마일렛
Original Assignee
마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 filed Critical 마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Publication of KR20140033448A publication Critical patent/KR20140033448A/ko
Application granted granted Critical
Publication of KR101976221B1 publication Critical patent/KR101976221B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5022—Mechanisms to release resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3644—Software debugging by instrumenting at runtime
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3037—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a memory, e.g. virtual memory, cache
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5021—Priority
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/508—Monitor

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Abstract

본 명세서에 기술되는 메모리 관리 시스템은 메모리가 이용되는 방식을 기술하는 애플리케이션으로부터 정보를 수신하고 애플리케이션 호스트가 메모리를 이용하기 위한 애플리케이션 요청에 대한 보다 많은 제어를 행할 수 있게 한다. 시스템은 애플리케이션이 이후에 메모리를 관리하는 데에 도움되는 메모리 할당에 대한 더 많은 정보를 명시할 수 있게 하는 애플리케이션 메모리 관리 API를 제공한다. 시스템은 또한 시스템과 작동하도록 수정되지 않은 애플리케이션에 보다 효율적인 메모리 관리에 참여하기 위한 일부 능력을 부여하도록 정적으로 및/또는 동적으로 레거시 애플리케이션을 분석하는 능력을 제공한다. 시스템은 애플리케이션에 의해 제공되는 정보를 레버리지하고 정보를 이용하여 보다 효율적으로 메모리를 관리하도록 애플리케이션 호스트 변경을 제공하며 애플리케이션의 메모리 이용으로 후크(hook)한다. 따라서, 시스템은 애플리케이션 호스트 행동을 향상시키고 애플리케이션이 컴퓨팅 리소스를 보다 효율적으로 사용할 수 있게 하는 메모리 관리를 위한 새로운 모델을 제공한다.

Description

수정되지 않은 애플리케이션을 위한 메모리 관리 모델 및 인터페이스{MEMORY MANAGEMENT MODEL AND INTERFACE FOR UNMODIFIED APPLICATIONS}
컴퓨터 시스템에서의 메모리 관리는 복수의 애플리케이션 및 운영 시스템이 메모리 이용에 동의하는 방식을 지칭한다. 각 컴퓨터 시스템이 고정된 양의 물리적 랜덤 액세스 메모리(RAM) 또는 다른 메모리를 구비하지만, 운영 시스템은 물리적 메모리와는 다른 메모리 크기를 나타내는 가상 메모리를 애플리케이션 및 운영 시스템 구성요소에 제시할 수 있다. 일부 경우에서, 애플리케이션이 다른 애플리케이션의 메모리를 우연히 또는 고의적으로 수정함으로써 다른 애플리케이션의 동작을 방해하는 것을 막기 위해서, 가상 메모리는 운영 시스템으로 하여금 각 애플리케이션이 메모리의 특정 부분에 액세스하는 것을 제한할 수 있게 한다. 운영 시스템은 일반적으로 애플리케이션 및 운영 시스템 구성요소 요청에 응답하여 메모리를 할당하고 자유화(free)하기 위한 하나 이상의 기능을 제공한다. 운영 시스템은 애플리케이션에 메모리 풀(pool)을 제공할 수 있으며, 이러한 메모리 풀로부터 애플리케이션은 메모리 청크(chunk)를 할당할 수 있다. 만약 애플리케이션 또는 애플리케이션들의 그룹이 함께 설치된 물리적 메모리보다 더 많은 양의 가상 메모리를 이용한다면, 운영 시스템은 페이징(paging) 또는 디스크 교체(swapping)라 불리는 프로세스에서의 교체 파일(swap file)을 통해 메모리의 명백한 크기를 확장하도록 더욱 느린 디스크 기반의 저장을 이용할 수 있다(즉, 메모리의 페이지를 디스크에 저장하고 검색함).
제공된 할당 및 자유화 기능과는 별개로, 운영 시스템은 애플리케이션이 메모리를 이용하는 방식에 대해 거의 알지 못한다. 다수의 컴퓨팅 디바이스는 메모리를 둘러싸는 특정한 제한을 포함한다. 예를 들어, 모바일 컴퓨팅 디바이스는 데스크톱 컴퓨터 시스템 상에서 전형적으로 이용가능한 것보다 훨씬 적은 양의 메모리를 포함할 수 있으며(또는 시스템이 에너지 소비를 감소시키도록 일부 메모리 전력을 감소시키길 원할 수 있음), 이는 얼마나 많은 애플리케이션이 동시에 구동할 수 있는지, 얼마나 많은 메모리를 각각의 애플리케이션이 요청/소비할 수 있는지 등과 관련된 디바이스에 대한 제한을 생성한다. 특정한 컴퓨팅 시스템 내에서 애플리케이션 코드를 호스트하는 다른 컴퓨팅 환경이 또한 환경의 메모리 이용에 대한 제한 또는 상한선을 강제할 수 있다. 예로서 VMware 및 MICROSOFT TM Virtual PC, 하이퍼바이저(hypervisor) 등과 같은 호스트에 제한된 리소스가 배치될 수 있다. 이러한 모든 상황에서, 효율적인 메모리 관리가 더욱 분명해진다.
새로운 컴퓨팅 플랫폼은 애플리케이션들 사이에서 공유되는 제한된 메모리의 문제를 해소하기 위해 도입된 새로운 기술 또는 다시 제안된 예전 기술을 갖는다. 예를 들어, 애플리케이션이 포어그라운드(foreground)에 있지 않을 때 (즉, 적극적으로 사용되고 있지 않을 때) 운영 시스템이 이를 셧다운(shot down)하고 더욱 느린 스토리지(예로서, 플래시 메모리 또는 다른 스토리지) 상의 애플리케이션의 메모리의 이미지를 저장하도록, 모바일폰 운영 시스템은 각 애플리케이션의 메모리 스냅샷(snapshot)을 생성할 수 있다. 애플리케이션이 선택되었을 때, 운영 시스템은 저장된 이미지를 메모리로 다시 로딩하고 애플리케이션을 시작한다. 애플리케이션은 자신이 셧다운 되었었다는 것조차 인식하지 못할 수 있다. 이러한 기술이 도움이 되지만, 운영 시스템은 여전히 메모리를 이용하기 위한 애플리케이션의 불분명한 요청을 겪는다. 현재 동적 메모리 이용과 관련하여 이루어지는 대다수의 결정이 런타임 중에 발견된 정보에 기초하여 이루어진다. 이러한 정보의 예는 할당된 메모리 세그먼트에 대한 참조(reference)의 사이즈 및 수를 포함한다. 이러한 정보는 그 다음 어떤 할당이 디스크에 페이징될지, 고성능 메모리로 캐시(cache)될지, 또는 일부 자동 메모리 관리 시스템 종류에 의해 자유화될지를 결정하도록 사용될 수 있다. 불행히도, 임의의 플랫폼이 잠재적으로 다수 해에 걸친 레거시 애플리케이션에 의해 제한되며, 따라서 메모리 관리만큼 넓게 퍼져있는 영역 내의 새로운 모델을 채택하는 것이 어렵다.
본 명세서에 기술되는 메모리 관리 시스템은 메모리가 이용되는 방식을 기술하는 애플리케이션으로부터 정보를 수신하고 애플리케이션 호스트가 메모리를 이용하기 위한 애플리케이션 요청에 대한 보다 많은 제어를 행할 수 있게 한다. 오늘날, 애플리케이션 호스트는 어떤 사이즈의 메모리가 각 요청에 의해 요청되는지 그리고 얼마나 많은 메모리 요청을 애플리케이션이 하였는지 외에 메모리의 애플리케이션 이용에 대해 거의 알지 못한다. 그러나 애플리케이션 호스트는 각 메모리 할당의 목적, 어떤 메모리 할당이 곧 사용될지, 만약 애플리케이션 호스트가 보다 많은 메모리를 필요로 했다면 어떤 메모리 할당이 쉽게 재생성될 것인지, 어떤 메모리 할당이 잠시 동안 사용되지 않을지, 그리고 따라서 애플리케이션의 성능에 영향을 미치지 않고 디스크에 페이징될 수 있는지 등을 알지 못한다. 불행히도, 애플리케이션 호스트가 이러한 유형의 결정을 내리는 업무를 맡았지만, 애플리케이션은 효율적으로 이러한 결정을 내리는 것에 대해 가장 많은 정보를 소유한다.
메모리 관리 시스템은 이러한 문제를 다양한 방식으로 극복한다. 먼저, 시스템은 애플리케이션이 이후에 메모리를 관리하는 데에 도움되는 메모리 할당에 대한 더 많은 정보를 명시할 수 있게 하는 애플리케이션 메모리 관리 애플리케이션-프로그래밍 인터페이스(application-programming inteface; API)를 제공한다. API는 또한 메모리가 언제 필요한지를 애플리케이션에 알리고 애플리케이션의 상호작용 없이 요구되는 메모리 할당을 사전적 조치로 자유화하고 재생성하기 위해 애플리케이션 호스트에 대해 능력을 제공할 수 있다. 다음으로, 시스템은 보다 효율적인 메모리 관리에 참여하기 위한 일부 능력을 시스템과 동작하도록 수정되지 않은 애플리케이션에 부여하기 위해 정적으로 및/또는 동적으로 레거시 애플리케이션을 분석하는 능력을 제공한다. 셋째로, 시스템은 애플리케이션에 의해 제공된 정보를 레버리지(leverage)하고 정보를 이용하여 보다 효율적으로 메모리를 관리하도록 애플리케이션 호스트 변경을 제공하고 애플리케이션의 메모리 이용으로 후크(hook)한다. 따라서, 메모리 관리 시스템은 애플리케이션 호스트 행동을 향상시키고 잠재적으로 애플리케이션이 보다 효율적으로 컴퓨팅 리소스를 사용할 수 있게 하는 메모리를 관리하기 위한 새로운 모델을 제공한다.
본 요약부는 아래의 상세한 설명에 추가로 기술되는 개념들의 선택을 단순화된 형태로 도입하도록 제공되었다. 본 요약부는 청구된 청구사항의 기본 특성 또는 중요 특성을 식별하기 위한 것이 아니며, 청구된 청구사항의 범주를 한정하도록 사용되는 것 또한 아니다.
도 1은 일 실시예에서 메모리 관리 시스템의 구성요소를 도시한 블록도.
도 2는 일 실시예에서의 메모리 관리 시스템의 운영 환경을 도시한 블록도.
도 3은 일 실시예에서 메모리의 할당 및 이용을 요청하기 위한 소프트웨어 애플리케이션 내의 메모리 관리 시스템의 프로세싱을 도시한 순서도.
도 4는 일 실시예에서 메모리를 할당 및 사용하라는 애플리케이션 요청을 수신하기 위한 호스트 내의 메모리 관리 시스템의 프로세싱을 도시한 순서도.
도 5는 일 실시예에서 메모리 할당 정보를 제공하도록 특별히 설계되지 않은 애플리케이션을 분석하기 위한 메모리 관리 시스템의 프로세싱을 도시한 순서도.
도 6은 일 실시예에서 개선된 메모리 정보에 대한 목록을 제공하고 애플리케이션을 정적으로 분석하는 메모리 관리 시스템의 프로세싱을 도시한 순서도.
도 7은 일 실시예에서 검출된 메모리 압력에 응답하여 메모리와 관련된 동작을 취하기 위한 메모리 관리 시스템의 프로세싱을 도시한 순서도.
도 8은 일 실시예에서 메모리가 이전에 호스트에 의해 수정된, 애플리케이션을 활성화하기 위한 메모리 관리 시스템의 프로세싱을 도시한 순서도.
본 명세서에는 메모리가 사용되는 방식을 기술하는 애플리케이션으로부터 정보를 수신하고 애플리케이션 호스트가 메모리를 이용하기 위한 애플리케이션 요청에 대해 보다 많은 제어를 수행할 수 있게 하는 메모리 관리 시스템이 기술되었다. 오늘날, 애플리케이션 호스트는 어떤 사이즈의 메모리가 각 요청에 의해 요청되는지 그리고 얼마나 많은 메모리 요청을 애플리케이션이 하였는지 외에 메모리의 애플리케이션 이용에 대해 거의 알지 못한다. 그러나 애플리케이션 호스트는 각 메모리 할당의 목적, 어떤 메모리 할당이 곧 사용될지, 만약 애플리케이션 호스트가 보다 많은 메모리를 필요로 했다면 어떤 메모리 할당이 쉽게 재생성될 것인지, 어떤 메모리 할당이 잠시동안 사용되지 않을지, 그리고 따라서 애플리케이션의 수행에 영향을 미치지 않고 디스크에 페이징될 수 있는지 등을 알지 못한다. 불행히도, 애플리케이션 호스트가 이러한 유형의 결정을 내리는 업무를 맡았지만, 애플리케이션은 효율적으로 이러한 결정을 내리는 것에 대해 가장 많은 정보를 소유한다. 이러한 충돌은 기본 레벨의 기능을 제공하고 어떠한 동작을 취해야 하는지를 추측하는 애플리케이션 호스트에 의해 오늘날 해결되었다. 다수의 경우에, 애플리케이션 호스트는 단지 애플리케이션이 메모리를 필요로 하기 전에 메모리를 디스크에 페이징할 수 있거나, 애플리케이션 호스트는 애플리케이션에게 거의 중요하지 않은 메모리를 관리하는 대규모의 노력을 소비할 수 있다.
메모리 관리 시스템은 본 명세서에서 추가로 기술되는 몇몇 방식들로 이러한 문제들을 극복한다. 먼저, 시스템은 이후에 메모리 관리에 도움되는 메모리 할당에 대한 보다 많은 정보를 애플리케이션이 명시할 수 있게 하는 애플리케이션 메모리 관리 애플리케이션-프로그래밍 인터페이스(API; application-programming interface)를 제공한다. API는 또한 메모리가 언제 필요한지를 애플리케이션에 알리고 애플리케이션의 상호작용 없이 요구되는 메모리 할당을 사전적 조치로 자유화하고 재생성하기 위해 애플리케이션 호스트에 대해 능력을 제공할 수 있다. 다음으로, 시스템은 보다 효율적인 메모리 관리에 참여하기 위한 일부 능력을 시스템과 동작하도록 수정되지 않은 애플리케이션에 주기 위해 정적으로 및/또는 동적으로 레거시 애플리케이션을 분석하는 능력을 제공한다. 셋째로, 시스템은 애플리케이션에 의해 제공된 정보를 레버리지(leverage)하고 정보를 이용하여 보다 효율적으로 메모리를 관리하도록 커널-레벨 운영 시스템(또는 호스트) 변경을 제공하고 애플리케이션의 메모리 이용으로 후크(hook)한다. 따라서, 메모리 관리 시스템은 애플리케이션 호스트 행동을 향상시키고 잠재적으로 애플리케이션이 보다 효율적으로 컴퓨팅 리소스를 사용할 수 있게 하는 메모리를 관리하기 위한 새로운 모델을 제공한다. 본 명세서에 기술된 바와 같은 애플리케이션 호스트는, 예로서 SILVERLIGHT TM, .NET에 의해 제공되는 런타임, 네이티브 Win32 호스트, 또는 VMware 및 Virtual PC에 의해 제공되는 다른 호스트 또는 가상 장치와 같은, 애플리케이션 또는 다른 유형의 호스트(예로서, 애플리케이션 자신은 운영 시스템 또는 가상화 서브시스템 상에서 구동한다)를 실행하는 운영 시스템을 지칭할 수 있다. 앞서 소개된 각각의 세 영역은 아래의 섹션에서 더욱 상세하게 기술된다.
수정된 애플리케이션
다수의 경우에서, 소프트웨어 개발자가 메모리 관리 시스템과 상호작용하도록 소프트웨어 애플리케이션을 수정하는 것이 가능할 수 있다. 적극적으로 개발된 애플리케이션에 있어서, 소프트웨어 개발자는 메모리 관리 시스템이 제공하는 이익을 위해서 메모리 관리 시스템을 채택하도록 선택할 수 있거나 또는 메모리 관리 시스템을 채택하도록 애플리케이션이 동작하는 특정 플랫폼에 의해 지시될 수 있다. 다수의 경우에, 애플리케이션은 애플리케이션이 사용할 가능성이 없는 것으로 할당된 메모리를 유지할 수 있다. 예를 들어, 사용자가 애플리케이션의 사용자 인터페이스의 일 부분으로부터 다른 부분으로 전이할 때, 애플리케이션은 사용자가 해당 인터페이스를 재방문할 경우에 대비하여 이전의 인터페이스로부터의 정보를 보관할 수 있다. 오늘날, 이러한 메모리는 적극적으로 사용되는 다른 메모리와 같이 호스트에게 필요한 것으로 보인다. 메모리 관리 시스템은 이러한 메모리의 우선순위가 낮아질 수 있도록, 이러한 상황을 호스트에게 알리는 방식을 애플리케이션에 대해 제공한다. 응답으로, 호스트는 페이징을 위한 우수한 후보로서 이러한 메모리를 선택할 수 있거나 또는 애플리케이션으로부터 추가된 정보로 인해 보다 효율적인 다른 메모리 관리 결정을 할 수 있다.
일부 실시예에서, 메모리 관리 시스템은 메모리 매니저가 런타임 동안 메모리 이용을 최적화하는 것에 대한 영리한 결정을 할 수 있게 하는 프레임워크 또는 애플리케이션-프로그래밍 모델을 제공한다. 이는 애플리케이션이 요청하는 임의의 주어진 메모리 대상에 대해 명시된 메모리 할당을 할당하고 채우는 데에 사용되는 동작들 및 메타데이터 모두를 수신하는 프레임워크/애플리케이션 프로그래밍 모델을 활용함으로써 달성된다. 메타데이터는 예로서 메모리의 우선순위, 할당되는 메모리의 양, 스크래치(scratch)로부터 메모리의 콘텐츠를 재생성하는 편의성(예로서, 콘텐츠는 알고리즘에 의해 계산가능하거나 파일로부터 로딩될 수 있다), 액세스의 빈도, 애플리케이션이 얼마나 금방 메모리를 사용할 수 있는지 등과 같은 메모리 할당의 본질 또는 목적을 기술하는 호스트에 애플리케이션이 전달하길 원하는 정보를 제공한다. 메모리를 할당하고 채우는데 사용되는 동작들은 애플리케이션의 요청에 따라 메모리를 자유화하고 자유화된 메모리를 후속하여 재생성할 수 있도록 호스트에 충분한 정보를 제공할 수 있다. 개발자가 메모리를 채우는데에 사용되는 동작들 및 메타데이터를 명시할 수 있게 함으로써, 메모리 관리 시스템은 애플리케이션에 의해 명시되는 원하는 용도와 일치하는 메모리 용도를 최적화할 수 있다.
메모리 관리 시스템에 의해 애플리케이션에 제공되는 API는 애플리케이션 프레임워크 또는 프로그래밍 모델을 통해 메모리 할당의 용도를 기술하는 메타데이터를 식별하도록 애플리케이션 개발자를 위한 수단을 제공한다. 또한, API는 애플리케이션 프레임워크가 개발자가 잘 알려진 기능을 통해 메모리를 채우거나 수정하기 위한 표준 수단을 활용하라는 지시를 하게 할 수 있다. 이는 메모리 관리 시스템이 성능 이유로, 낮은 메모리 이용가능성의 기간 동안 (즉, 메모리를 자유화하기 위한 기회 비용이 이후에 메모리를 재할당하고 다시 채우기 위한 비용보다 더 높을 때) 메모리를 자유화하기 위해 또는 다른 목적을 위해 기회주의적으로 메모리를 채울 수 있게 한다.
메모리 이용을 최적화하는 것은 당업계에서 다수의 기술을 포함할 수 있지만, 성능 또는 사이즈에 최적화하는 것을 일반적으로 의미할 것이다. 성능의 경우에, 최적화하는 것은 만족시키기 위한 수단이 이용가능하면 아직 필요하지 않은 메모리 할당이 발생할 수 있게 하는 것을 의미할 수 있다. 만약 현재 CPU 이용도가 낮고 애플리케이션이 유휴 상태면 이것이 바람직할 수 있다. 일부 경우에, 메모리를 할당하라는 애플리케이션의 요청은 그 시간에 어떤 것도 할당하지 않고 미래의 참조를 위해 호스트가 저장하는 노트가 될 수 있다. 이후에, 애플리케이션이 API를 통해 메모리를 사용하도록 요청할 때 또는 호스트가 요청을 만족시키기에 적절한 시간을 결정할 때, 메모리 관리 시스템이 실질적으로 요청된 메모리를 할당한다. 사이즈의 경우에서, 최적화하는 것은 현재 할당된 메모리 및 미래의 메모리 필요성에 기초하여 결정을 하거나 메모리 풋프린트를 감소시키는 것을 의미할 수 있다.
애플리케이션과 호스트 사이의 실제 인터페이스는 당업자에 의해 인지되는 다양한 형태를 취할 수 있다. 예를 들어, 애플리케이션은 각 할당 유형에 대한 할당 함수를 제공할 수 있고 할당 요청에서 호스트에 할당에 대한 포인터 또는 참조를 전달할 수 있다. 호스트가 할당을 수행할 준비가 되었을 때, 호스트는 제공된 할당 기능을 적용하며 애플리케이션은 규칙적인 메모리 할당 함수를 이용하여 메모리를 생성한다. 유사하게, 애플리케이션은 호스트가 메모리의 자유화, 메모리의 이동, 서로 다른 유형의 스토리지로의 메모리 콘텐츠 전환 등을 요청할 수 있도록, 다른 함수에 참조를 전달할 수 있다. 동일한 개념이 할당에도 사용될 수 있으며-애플리케이션이 운영 시스템으로부터 메모리를 요청할 때, 운영 시스템은 다수의 요인들에 기초하여 할당을 연기할 수 있다. 운영 시스템이 할당할 준비가 되었을 때 (할당된 메모리와 함께) 기능 참조가 다시 호출되거나 또는 이벤트가 일어난다(또는 유사한 메커니즘). 인터페이스는 또한 메모리 사이즈(요청된 사이즈와 다를 수 있음), 우선순위, 캐싱 참조, 페이징 가능성, 메모리가 채워지는 방식, 메모리에 대한 종속성 또는 참조, 메모리가 업데이트 되는지 여부 등과 같은 메타데이터를 수신할 수 있다. 일부 실시예에서, 시스템은 각 유형의 메모리 할당을 정의하도록 할당이 획득하는 메모리 인터페이스 클래스를 제공한다. 클래스는 애플리케이션-명시된 할당 함수를 검색하기 위한 GetPointer 함수, 또는 다른 메모리 핸들링 태스크를 수행하도록 함수를 검색하기 위한 다른 GetX 함수를 포함할 수 있다. 이와 달리 또는 이에 더하여, 애플리케이션은 종래의 방식으로 할당할 수 있고 그 다음 할당된 메모리를 호스트로 등록하고 본 명세서에 기술된 추가적인 정보를 할당된 메모리와 연관시키도록 명시하는 RegisterPointer 함수를 호출한다. 아래의 의사 코드(pseudo code)는 애플리케이션이 이용할 수 있는 하나의 메모리 클래스의 예시를 제공한다.
CMemChunk // base class for all memory allocations
{
<Global List of Allocations>
...
};
CMyMemory : public CMenChunk
{
Allocate (size);
Fill () { <how to fill memory> } // override
Attributes <e.g.,priority,pageability, ect.>
};
이와 달리 또는 이에 더하여, 개발자는 현존하는 메모리 할당을 식별하고 각각의 할당, 액세스, 또는 다른 메모리 상호작용과 관련된 메타데이터 및 추가적인 파라미터를 명시하기 위해 본 명세서에 기술된 프레임워크를 소스 주석 언어(SAL) 또는 다른 마크업(markup)을 이용하여 애플리케이션 코드에 도입할 수 있다.
일부 실시예에서, 메모리 관리 시스템은 단일 애플리케이션 내에서 동작할 수 있으며 커널 또는 다른 호스트와 공유되지 않을 수 있다. 애플리케이션은 향상된 메모리 관리로부터 이익을 얻을 수 있으며, 향상된 메모리 관리 자체의 내부 메모리 관리자는 본 명세서에 기술된 프레임워크를 이용함으로써 제공된 추가적인 정보로 수행할 수 있다. 일부 경우에, 호스트는 애플리케이션이 크로스-애플리케이션 이익을 획득하도록 호출할 수 있고 호스트로 하여금 잘 정의된 메모리 할당 및 사용을 이용할 수 있게 하는 등록 함수를 제공할 수 있다. 예시로서, 애플리케이션이 스캔의 속도를 높이기 위해서 임의의 더 적은 관련성을 가진 메모리를 언로드(unload)할 수 있도록, 시스템은 악성코드 스캔(malware scan) 이전에 애플리케이션에 통지할 수 있다. 다른 예시로서, 애플리케이션은 CPU가 유휴 상태에 들어가기 이전에 선제적으로 메모리를 할당할 수 있으며, 그에 따라 사용자가 무언가를 하고 CPU가 실행을 재개할 때 애플리케이션은 이벤트에 신속하게 응답할 수 있다(전력 상태 변화에 대한 반응성을 개선한다).
수정되지 않은 애플리케이션
소프트웨어 개발자가 메모리 관리 시스템과 상호작용하도록 소프트웨어 애플리케이션을 수정하는 것이 가능하지 않은 경우 또는 시스템이 수정되지 않은 애플리케이션(즉, 시스템과 작동하도록 특별히 설계되지 않은 애플리케이션)과 동작하도록 구현된 경우, 시스템에 메모리 관리 이득을 제공하는 것이 여전히 가능하다. 이를 위해서, 시스템은 애플리케이션이 자신의 메모리를 어떻게 사용하는지를 기술한 정보를 수집한다(예로서, 정적 분석 및/또는 애플리케이션 프로파일링에 기초함- 이는 애플리케이션 구동, 메모리 할당 방해 및 애플리케이션의 런타임에 걸친 이용 주시를 포함). 이러한 정보는 성능 특징을 결정할 때 유용하며 애플리케이션의 호스트의 메모리 관리자에 의해 현명하게 사용될 수 있다. 이러한 정보가 사용될 수 있는 방식의 예시는 지능적 가비지(garbage) 수집, 지능적 디스크로의 페이징, 더 높은 성능 메모리 캐시로의 지능적 캐싱 및 애플리케이션이 마주칠 수 있는 잠재적 메모리 제한에 대한 사용자 경고도 포함한다.
바이너리의 정적 분석을 활용하고, 바이너리의 행동의 런타임을 분석하며, 바이너리를 계장화(instrumenting)함으로써, 임의의 바이너리의 주어진 메모리 할당 및 그러한 할당의 이용에 대한 추가적인 정보를 수집하는 것이 가능하다. 이러한 정보는 물리적 메모리 내의 할당의 위치 및 로딩/언로딩 주변의 보다 지능적인 행동을 구동하도록 사용될 수 있다. 메모리 관리 시스템은 할당 자체의 잠재적 또는 실제 용도를 기술하는 메타데이터를 이용하여 애플리케이션 메모리 할당에 자동으로 주석 첨가(annotate)하기 위한 수단을 제공한다. 이러한 분석은 어떠한 개발자 상호작용 또는 현존하는 애플리케이션의 재저작(re-authoring)을 필요로 하지 않고 런타임 동안 동적으로 또는 바이너리에 대해 정적으로, 자동 실행될 수 있다. 수행되면, 분석은 시스템에 의해 캐시될 수 있으며, 따라서 호스트 운영 시스템은 미래에 애플리케이션을 처리하는 방식을 인지한다. 분석은 또한 단지 로컬식으로 캐시되지 않고 다른 클라이언트에 의한 발견을 위해 공개될 수 있다. 또한, 정보가 선택적 편집을 위해 사용자에게 노출되는 것이 가능하며, 이는 관리자 또는 사용자가 애플리케이션의 메타데이터 및 애플리케이션 호스트가 애플리케이션의 메모리 할당을 처리하게 될 방식을 맞춤화하는 것을 가능케 한다.
애플리케이션의 메모리 할당에 대한 추가적인 정보를 유도하기 위해서 정적 및 동적 분석을 이용하는 것이 가능하며, 이러한 정보는 시스템 메모리 할당 및 애플리케이션의 전체적 관리를 지시하는 것을 돕도록 사용될 수 있다. 예시로서 메모리가 터치되었을 때, 다른 메모리 세그먼트가 이러한 메모리 할당을 채우는 것을 돕도록 사용되는지 여부를 결정하는 것이 가능하다. 만약 이러한 메모리 할당이 다른 할당에 의존한다면, 이러한 의존성이 표시될 수 있거나 또는 메모리 할당이 입력 없이 생성되지 않았음을 나타내도록 비트에 의해서만 간단히 기록될 수도 있다. 정적 분석은 어디에서 소프트웨어 코드가 메모리를 터치하는지, 메모리가 어떻게 사용되는지, 메모리가 어떻게 채워지는지, (예로서, 만약 한번 기록되고/다수 판독되었다면(WORM;write once/read many) 코드 경로가 얼마나 흔한지, 그리고 얼마나 자주 메모리가 사용되는지를 결정할 수 있다. 동적 분석은 모든 할당 및/또는 액세스를 계장화할 수 있으며(프로파일러와 유사함), 코드의 동작에 영향을 미치는 시스템 환경, 동작에 영향을 미치는 사용자 설정 및 정적으로 결정하기 어렵거나 정적으로 결정하는 것이 이용가능하지 않은 다른 데이터를 캡처할 수 있다.
일부 실시예에서, 메모리 관리 시스템은 애플리케이션이 분석된 후에 애플리케이션의 메모리 이용의 다른 기술 또는 목록을 출력한다. 이것은 시스템으로 하여금 분석의 결과를 캐싱하고 애플리케이션의 이래의 실행에 대한 결과를 재사용할 수 있게 한다. 운영 시스템은 처음에 (또는 애플리케이션 시각화의 시퀀싱과 같은 프로세스 동안) 애플리케이션 바이너리가 실행하는 이러한 분석을 수행하고, 그 다음에 바이너리가 실행하는 각 시간에 사용하기 위해 이 분석을 저장하도록 시스템과 설계될 수 있다. 커널 또는 다른 호스트는 목록 데이터를 판독할 수 있고 애플리케이션이 메모리를 사용하는 방식을 기술하는 추가적인 정보를 통해 적절한 동작을 취할 수 있다. 애플리케이션 이용은 시간에 걸쳐 달라질 수 있으며, 따라서 목록 또는 다른 캐시는 가끔 동적으로 업데이트될 수 있다. 일부 경우에, 시스템은 각 할당에 대한 메모리의 전체 페이지를 할당할 수 있으며, 그에 따라 각 메모리 액세스는 커널이 메모리가 사용되는 방식을 제어할 수 있게 하는 페이지 폴트( page fault)를 트리거링하고 본 명세서에 추가로 기술되는 실제 메모리 할당과 메모리에 대한 애플리케이션 참조 사이에서의 간접성 유형을 제공한다.
일부 실시예에서, 시스템은 애플리케이션 메모리 행동에 대한 기록을 제공할 수 있다. 이것은 분석에 대한 다른 이용이며 관리자가 어떤 서버 또는 가상 버신 상에서 잘 구동될 지와 같은 애플리케이션에 대한 결정을 내리는 것을 도울 수 있다. 시스템은 또한 예를 들어 모바일폰 애플리케이션 스토어의 사용자가 애플리케이션을 다운로드 하기 이전에 애플리케이션이 모바일폰의 이용가능한 메모리를 이용하는 방식(예로서, 높은 이용, 낮은 이용 등)을 알 수 있도록 메모리 이용의 시장 속도(marketplace rating)를 제공할 수 있다. 관리자는 또한 메모리 소비에 대한 수집된 메타데이터에 기초하여 이러한 정보를 다양한 시스템에 걸친 소프트웨어의 IT 배치에 사용할 수 있다.
메모리 관리 시스템은 시스템이 유휴 중이거나 활용되지 않을 때 선제적으로 메모리를 할당하고 잠재적으로 메모리를 채우기 위해서 메모리 이용 분석으로부터 파생된 정보를 이용할 수 있다. 애플리케이션의 미래의 메모리 이용을 아는 것은 시스템으로 하여금 보다 효율적으로 메모리를 할당하고 시스템이 더 무거운 부하를 가질 때 사용될 수 있는 메모리를 할당하기 위해 시스템이 활용되지 않을 때 시간을 레버리지할 수 있게 한다. 이것은 더 무거운 부하가 보다 쉽게 완료된 작업에 의해 이용가능하게 된 다른 리소스 또는 더 많은 프로세싱에 대한 액세스를 가질 수 있게 한다.
호스트 수정
메모리 관리 시스템은 애플리케이션의 분석을 통해 결정되거나 애플리케이션에 의해 제공되는 메모리 이용에 대한 추가적인 정보를 수신하도록 커널 또는 애플리케이션 호스트에 대한 수정을 포함한다. 종래의 소프트웨어 메모리 관리와는 달리, 본 명세서에 기술된 애플리케이션으로부터 전달되는 다른 정보 및 메타데이터에 의해 제공되는 메모리 이용에 추가된 시야로 인해, 커널은 애플리케이션의 지식 또는 동작 없이 메모리를 더욱 효율적으로 관리할 수 있다. 애플리케이션이 인식되지 않거나 커널의 메모리 관련 동작들과 관련되지 않도록, 커널은 후에 애플리케이션에 어떤 동작들이 취해졌는지를 알려줄 수 있거나 또는 애플리케이션이 메모리를 필요로 할 때까지 메모리가 준비되어 있도록 메모리를 관리할 수 있다. 커널은 그 다음 (예로서, 디스크 스토리지를 늦추기 위해 덜 중요하거나 또는 사용될 가능성이 낮은 메모리를 오프로딩(offloading) 함으로써) 보다 나은 페이징을 수행할 수 있고, 만약 메모리 압력이 발생하면 메모리를 자유화할 수 있으며, 커널에 의해 제공되는 운영 환경을 이용하여 하나 이상의 애플리케이션 대신 메모리를 관리하기 위한 다른 동작들을 취할 수 있다. 예를 들어, 커널은 더 작은 단편화에 대해 메모리를 더욱 잘 할당할 수 있다.
메모리는 운영 시스템에서 제한된 리소스이며, 그러므로 커널이 메모리가 필요에 따라 애플리케이션으로부터 메모리를 발견할 수 있도록 할당되는 위치를 적절하게 추적하는 것이 중요하다. 하나의 솔루션은 애플리케이션이 메모리에 할당된 것과 같이 메모리에 우선순위를 할당하는 것이다. 따라서, 시스템이 메모리가 부족하다고 결정했을 때, 커널은 가장 낮은 우선순위 메모리가 어디에 있는지를 결정할 수 있고, 더 높은 우선순위 메모리를 갖는 다른 애플리케이션의 퍼포먼스에 영향을 미치지 않고 해당 메모리를 할당해제 또는 페이징할 수 있다.
통상적으로, 메모리의 우선순위 및 애플리케이션으로의 배분은 커널에 의해 결정된다. 시스템이 메모리가 부족한 채로 구동할 때, 커널은 더 높은 우선순위를 갖는 애플리케이션에 의해 사용되는 메모리를 임의로 자유화할 수 있으며, 그에 따라 애플리케이션의 성능을 방해하거나 저하시킬 수 있다. 대신, 더 낮은 우선순위 메모리가 먼저 할당해제되어야만 한다. 애플리케이션이 어디로부터 메모리를 자유화할지를 커널이 결정하는 방식에 관련된 흥미로운 측면들이 존재한다. 하나의 솔루션은 애플리케이션이 그들 중에서 메모리 리소스에 대한 우선순위 순서가 무엇인지를 결정하는 것이다. 메모리 우선순위 계획은 할당 또는 할당해제시에 그들에게 할당되거나 할당해제되는 메모리의 우선순위를 할당할 것을 애플리케이션에 요청한다. 따라서, 메모리 압력이 존재할 때, 커널은 우선순위에 의해 랭크된 메모리 맵을 가지며 더 낮은 우선순위 메모리를 먼저 자유화하고 위치시킬 수 있다. 이와 달리, 커널은 자유화될 필요가 있는 할당의 리스트로 애플리케이션에 통지를 전송할 수 있다. 메모리 관리 시스템은 운영 시스템에 의해 완전하게 호스팅될 수 있거나, 또는 운영 시스템과 애플리케이션 사이에서 협조적일 수 있다.
우선순위 모델은 메모리 요청이 이루어질 때마다 애플리케이션을 요약하는 메모리 할당 API를 생성함으로써 구현될 수 있다. 이것은 또한 등록하지 않는 애플리케이션을 유용할 수 있다. 이러한 API를 활용함으로써, 애플리케이션이 적극적으로 메모리 우선순위를 관리하지 않고도 애플리케이션 및 우선순위가 서브시스템에 의해 자동으로 추적된다. 커널 객체는 모든 등록, 계산, 시그널링 및 메모리 관리 기능을 포함하며 따라서 각 애플리케이션이 단지 이러한 객체를 호출하기만 하면 된다(또는 수정되지 않은 애플리케이션의 경우에 애플리케이션 대신 호출된다).
대안적인 솔루션은 현재 구동중인 다양한 애플리케이션을 계속 추적하는데에 사용되는 커널 외의 마스터 애플리케이션을 갖는 것이다. 애플리케이션이 메모리를 요청할 때, 이는 마스터 애플리케이션에 등록된다. 따라서, 애플리케이션이 무반응이 되었을 때, 마스터 애플리케이션은 메모리를 회수하기 위해 좀비 애플리케이션을 끝낼지 또는 메모리가 필요할 때 메모리가 애플리케이션으로 반환될 수 있도록 계속 유지할지 여부를 결정할 수 있다.
커널 또는 호스트는 다양한 메모리 관리 결정을 보다 효율적으로 하기 위해 개선된 메모리 정보를 이용할 수 있다. 예를 들어, 저전력 디바이스의 커널은 배터리 수명을 절약하기 위해 메모리의 뱅크를 턴-오프 하도록 선택할 수 있다. 시스템은 뱅크 내의 메모리가 턴-오프 되는 프로세스를 끝내거나 교환할 수 있다. 시스템은 또한 셧오프될 수 있는 일부 비어있는 뱅크를 획득하도록 몇몇 뱅크에 걸쳐 퍼져있는 메모리를 디프래그(defragment) 할 수 있다. 다른 예시로서, 커널은 일부 메모리 할당을 (클라우드 기반의 스토리지 시설을 포함하는) 다른 디바이스로 푸시하도록 선택할 수 있다. 다수의 작은 풋프린트(footprint), 저전력 운영 시스템은 페이징의 개념을 갖지 않으며, 따라서 이러한 경우에 메모리 할당은 다른 디바이스/서비스에 의해 호스팅된 REST(Representational State Transfer) 인터페이스 상에서 지원될 수 있다. 데이터베이스 스냅샷을 통해 스크롤링(scrolling)하는 것과 유사한 방식으로, 애플리케이션은 메모리 내의 전체 데이터베이스를 갖지 않지만, 데이터베이스 서비스/서버로부터 조각들이 전달된다. 애플리케이션은 전체 데이터베이스가 아닌 스냅샷을 보고 있다는 인식을 갖지 않는다. 메모리를 확신을 가지고 주위로 이동시키거나 메모리를 할당해제할 수 있는 것은, 커널/호스트가 메모리를 더욱 잘 관리할 수 있게 하며 여전히 메모리 이용가능성의 애플리케이션 예상을 유지시킨다.
일부 실시예에서, 시스템은 메모리에 더하여 다른 호스트-레벨 객체 또는 구성요소와 사용된다. 예를 들어, 시스템은 디스플레이가 종료되었을 때 그래픽 처리 장치(GPU)를 셧오프할 수 있거나, 또는 연관된 하드웨어가 사용되고 있지 않거나 일부 시간에 사용되지 않을 때 개별적인 드라이버를 셧오프할 수 있다. 시스템은 또한 먼저 메모리를 디프래그하고 시스템이 기상할 시간이 되었을 때 쉽게 재로딩될 수 있는 디스크로 메몰 할당의 선형 스트림을 스트리밍하도록, 시스템의 활동정지(hibernation)를 위해 사용될 수 있다. 전체 물리적 메모리와 동일한 사이즈를 갖는 파일을 저장하는 종래의 활동정지와는 다르게, 메모리 관리 시스템은 애플리케이션이 불필요하거나 쉽게 복구되는 메모리(또는 애플리케이션을 위해 그렇게 할 수 있는 메모리)를 활동정지 이전에 자유화하도록 권고할 수 있으며, 따라서 더 적은 양의 활동정지 데이터를 저장할 수 있다. 메모리에 더하여 관리되는 다른 아이템은 파일 핸들, 타이머, 커널 객체 등을 포함할 수 있다. 시스템은 메모리 이용과 같은 이들 아이템에 대한 이용 정보를 수신할 수 있다(또는 이를 정적 및 동적 분석으로부터 결정할 수 있다).
일부 실시예에서, 메모리 관리 시스템은 각 메모리 할당과 연관된 전력 상태를 수신한다. 예를 들어, 전력 레벨 X에서, 시스템은 일부 메모리 할당이 더 이상 필요하지 않다고 결정할 수 있다. 이것은 해당 전력 레벨에서 필요하지 않은 임의의 메모리를 오프로딩함으로써 더 낮은 전력 모드로 배터리 제한된 디바이스를 전환하게 할 수 있다. 예를 들어, 모바일폰은 전화 호출에 응답하거나 사용자에게 새로운 메일을 알려주기 위해 메모리 내의 충분한 애플리케이션 데이터를 유지할 수 있지만, 다른 더 낮은 우선순위 기능들 또는 애플리케이션들은 언로드할 수 있다. 일부 경우에서, 애플리케이션은 일부 더 낮은 전력 상태에서 메모리를 이용하기 전에 포인터 유효성을 입증해야할 수 있지만, 더 높은 전력 상태에서는 메모리에 대한 정상 액세스를 가질 수 있다. 이는 임의의 주어진 플랫폼에 대한 호스트와 애플리케이션 사이의 거래에서의 보장으로서 제공될 수 있다.
시스템 구성요소 및 운영 환경
도 1은 일 실시예에서 메모리 관리 시스템의 구성요소를 도시한 블록도이다. 시스템(100)은 메타데이터 수신 구성요소(105), 필링 내역((fill specification)) 구성요소(110), 할당 요청 구성요소(115), 메모리 참조 구성요소(120), 애플리케이션 인터페이스 구성요소(125), 정적 분석 구성요소(130), 동적 분석 구성요소(135), 호스트 구성요소(140), 요청 수신 구성요소(145), 요청 저장 구성요소(150), 할당 구성요소(155), 메모리 동작 구성요소(160) 및 데이터 스토어 구성요소(165)를 포함한다. 이들 각각의 구성요소들은 본 명세서에서 추가로 기술될 것이다.
메타데이터 수신 구성요소(105), 필링 내역 구성요소(110), 할당 요청 구성요소(115) 및 메모리 참조 구성요소(120)는 시스템(100)이 애플리케이션에 노출시키는 메모리 프레임워크를 함께 구성한다. 보다 효율적인 메모리 관리를 위해서 자신의 애플리케이션 코드를 수정하고자 하는 개발자는, 호스트 또는 커널이 애플리케이션을 대신하여 보다 효율적으로 메모리를 관리할 수 있게 하는 애플리케이션을 생성하도록 자신의 애플리케이션으로부터 그들의 구성요소를 레버리지할 수 있다.
메타데이터 수신 구성요소(105)는 메모리가 애플리케이션에 의해 사용되는 방식을 기술하는 애플리케이션 호스트에 정보를 제공하는 각 메모리 할당과 연관된 정보를 수신한다. 예를 들어, 메타데이터는 애플리케이션에 대해 할당이 얼마나 쉽게 액세스 가능해야만 하는지 또는 애플리케이션 플랜이 얼마나 자주 할당과 연관된 메모리에 액세스하는지를 나타낼 수 있다. 메타데이터는 또한 메모리 콘텐츠가 얼마나 생성하기 어려운지, 따라서 만약 콘텐츠가 자유화되거나 디스크에 페이징되면 애플리케이션 또는 호스트가 메모리 콘텐츠를 대체하기 얼마나 어려울지를 나타낼 수 있다. 메타데이터 수신 구성요소(105)는 메모리가 메타데이터를 제공하기 위한 후속 API 내에 이미 할당된 후에 또는 메모리 할당 API에 대한 호출 내의 메타데이터를 수신할 수 있다.
필링 내역 구성요소(110)는 특정 메모리 할당의 콘텐츠가 채워지는 방식을 기술하는 정보를 수신한다. 메모리의 콘텐츠는 디스크 상에 저장된 파일의 콘텐츠를 판독하는 것, 입력 데이터에 대한 하나 이상의 계산을 수행하는 것, 사용자 입력, 네트워크 액세스된 정보(예로서, 데이터베이스 또는 인터넷) 등과 같은 다양한 소스들로부터 올 수 있다. 일부 실시예에서, 애플리케이션은 호스트가 호스트에 의해 결정된 시간에 메모리 콘텐츠를 채우기 위한 기능을 적용할 수 있도록 메모리 채우기 기능을 호스트에게 전달한다. 프로세싱 및 다른 리소스를 효율적으로 사용하기 위해서, 호스트는 리소스가 활용되지 않거나 유휴화될 때까지 메모리를 채우는 것을 지연시키도록 선택할 수 있다. 또한, 호스트는 다른 용도를 위해서 앞서 채워진 메모리를 해제하거나 자유화하며, 애플리케이션이 메모리를 사용할 것이라는 예상에 앞서 메모리를 이후에 재할당하고 다시 채우는 자유를 가질 수 있다. 수신된 메타데이터는 애플리케이션이 언제 메모리를 사용할 것인지를 알기 위해 호스트가 사용하는 정보를 제공할 수 있거나, 또는 호스트가 메모리의 현재 상태를 검사할 수 있도록 각각이 메모리를 이용하고자 시도하기 전에 애플리케이션이 호스트에게 알릴 수 있다.
할당 요청 구성요소(115)는 수신된 메타데이터 및 필링 내역에 기초하여 메모리를 할당하라는 요청을 애플리케이션으로부터 호스트로 제출한다. 호스트가 요청을 수신함에도 불구하고, 응답으로 요청을 즉시 서비스할지 또는 다른 적절한 시간까지 기다릴지 여부는 호스트에 달려있다. 극단적인 경우에, 호스트는 액세스될 준비가 될 때까지 어떠한 메모리도 할당하지 않을 수도 있으며, 애플리케이션이 메모리를 필요로 하거나 작업을 위해 수행될 수 있도록 메모리가 애플리케이션을 위해 할당되어야 할 때 가능한 마지막 순간까지 호스트로 하여금 제한된 리소스를 보존할 수 있게 한다. 할당 요청 구성요소(115)는 호스트에 의해 관리되는 데이터 스토어 내에 제출된 요청을 저장하며 후에 메모리 관리 동작에서 사용하기 위해 수신된 메타데이터 및 필링 내역을 포함한다.
메모리 참조 구성요소(120)는 앞서 제출된 할당 요청의 대상이었던 메모리에 애플리케이션이 액세스하기 전에 애플리케이션으로부터 표지(indication)를 수신한다. 호스트가 메모리를 이용가능하지 않게 하거나 자신이 선택할 때까지 실제로 메모리를 할당하는 것을 지연시킬 수 있기 때문에, 애플리케이션이 메모리를 사용할 준비가 될 때까지 애플리케이션은 메모리가 이용가능하다고 보장하기 위한 방법을 필요로 한다. 메모리 참조 구성요소(120)는 이러한 목적을 수행하며, 애플리케이션이 특정 메모리 할당에 액세스할 준비가 되었음을 나타낼 수 있게 한다. 이에 대한 응답으로, 호스트는 (만약 메모리가 이미 이용가능하다면) 실제 메모리 위치에 대한 포인터를 애플리케이션에 전달할 수 있거나, 또는 (만약 메모리가 현재 할당되지 않았다면) 수신된 필링 내역 및 메타데이터에 기초하여 메모리를 생성하고 채울 수 있다. 애플리케이션은 호스트가 메모리 관리 결정에서 다시 자유롭게 메모리를 포함하도록 메모리를 해제하라는 표지를 전송할 수 있다.
애플리케이션 인터페이스 구성요소(125)는 메모리 할당의 사용을 협상하기 위해 애플리케이션과 호스트 사이의 통신 인터페이스를 제공한다. 애플리케이션에 의해 제공되는 사용자 정의된 기능을 이용하는 애플리케이션의 메모리와 상호작용하도록 호스트에 의해 사용되는 베이스 클래스 또는 기능뿐 아니라, 메모리 할당을 요청하고 할당에 대한 정보를 명시하도록 인터페이스는 애플리케이션에 의해 사용되는 하나 이상의 기능 또는 베이스 클래스를 포함할 수 있다. 애플리케이션과 호스트 사이의 개선된 통신은 호스트가 메모리의 애플리케이션으로의 가시성(visibility)의 일반 레벨보다 훨씬 더 높은 레벨을 가질 수 있게 하고, 호스트가 유한 리소스를 보다 효율적으로 공유하는 다양한 애플리케이션 대신 메모리를 관리할 수 있게 한다.
메모리 관리 시스템(100)을 명확하게 사용하도록 설계되지 않은 애플리케이션에 대해서, 애플리케이션 인터페이스 구성요소(125)는 정적 및/또는 동적 분석에 의해 결정되는 임의의 계장화된(instrumented) 애플리케이션 코드 사이의 상호작용을 제공하며, 앞서 기술된 것과 유사한 방식으로 호스트와 상호작용한다. 시스템(100)을 이용하도록 설계되지 않은 애플리케이션을 이용하여, 시스템(100)은 메모리 할당의 목적 또는 다른 명세에 대한 정보를 거의 가지지 않을 수 있으며, 시스템(100)이 애플리케이션의 정적 및 동적 분석을 통해 발견할 수 있는 정보로 제한될 수 있다. 그러나, 이러한 분석은 여전히 레거시(legacy) 애플리케이션에 의해 할당된 메모리를 보다 효율적으로 관리하기에 유용한 메타데이터를 발견할 수 있다. 일부 경우에서, 시스템(100)은 애플리케이션이 메모리를 채우는 방식을 자동으로 검출할 수 있고 애플리케이션의 명확한 협력 없이 이전에 기술된 것과 동일한 유형의 주문에 따른 메모리 콘텐츠의 채우기를 수행할 수 있다.
정적 분석 구성요소(130)는 애플리케이션이 메모리를 이용하는 방식을 결정하도록 애플리케이션 이진 코드 또는 다른 애플리케이션 코드를 정적으로 분석한다. 구성요소(130)는 이진 코드, 중간 코드(intermediate code)(예로서, MICROSOFT TM 중간 언어(IL) 코드), 또는 애플리케이션의 다른 컴파일된 또는 실행가능한 버전을 분석할 수 있다. 정적 분석은 실질적으로 지난 몇 년에 걸쳐 발전되어 왔으며, 애플리케이션 바이너리(binary)가 무엇을 어떻게 하는지를 결정하기 위한 다수의 기술이 당업계에서 잘 알려져 있다. 메모리 관리 시스템(100)은 애플리케이션이 메모리를 할당하고 이용하는 영역에 특히 초점을 맞추기 위해서 이러한 기술을 이용한다. 구성요소(130)는 애플리케이션의 특정 동작을 방해하거나 정보를 수신하도록 애플리케이션 바이너리를 계장화할 수 있으며 방해된 동작들을 새롭거나 추가적인 동작들로 대체할 수 있다. 예를 들어, 만약 구성요소(130)가 메모리 할당 기능에 대한 호출을 발견하면, 구성요소(130)는 정적 분석으로부터 이용가능한 임의의 메타데이터를 수집할 수 있고 메타데이터를 수신할 수 있는 할당 기능의 버전을 파라미터로서 호출할 수 있다. 이러한 방식으로, 호스트는 마치 애플리케이션이 이러한 정보를 제공하도록 자신의 개발자에 의해 수정된 것과 같이 애플리케이션으로부터 메타데이터 정보를 수신한다. 유사하게, 메모리 참조를 기술하는 필링 내역 및 정보가 호스트에게 제공될 수 있도록, 시스템은 애플리케이션이 특정 메모리 할당을 채우거나 액세스하는 방식을 결정할 수 있다.
동적 분석 구성요소(135)는 정적 분석으로 결정하기 어려운 애플리케이션의 메모리 사용과 관련된 추가적인 정보를 수집하도록 실행중인 애플리케이션을 동적으로 분석한다. 종종 애플리케이션은 (단계들이 그러한 방식으로 나타나기 때문에 의도적으로 또는 단순하게) 정적 분석을 방해하는 프로그래밍 단계들을 포함한다. 동적 분석은 외부 구성요소로부터 수신된 응답들의 콘텐츠 및 애플리케이션에 의해 사용되는 메모리의 실제 콘텐츠와 같은 이용가능한 정보를 가지며, 이에 대해 정적 분석 중에 오직 추측 또는 근사치만이 이용가능하다. 따라서, 동적 분석은 메모리 용도 및 정적 분석 동안 발견되지 않은 다른 애플리케이션 동작을 발견할 수 있다. 구성요소(135)는 또한 정적 분석의 결과를 확인하도록 동적 분석을 이용할 수도 있다. 동적 분석 구성요소(135)는 추가로 레거시 애플리케이션으로 하여금 시스템(100)에 의해 제공된 적어도 일부 기능을 레버리지할 수 있게 하도록 결정된 정보를 호스트에 제공한다.
호스트 구성요소(140)는 애플리케이션이 구동하는 환경을 포함하며 시스템(100)에 의해 제공되는 메모리 관리에 대한 액세스를 제공한다. 플랫폼에 의존하여, 호스트는 다양한 소프트웨어 엔티티를 포함할 수 있다. 종래의 데스크톱 컴퓨팅 시스템에 있어서, 호스트는 커널 및 드라이버와 같은 다른 커널 모드 소프트웨어 코드를 포함할 수 있는 운영 시스템이다. 관리된 소프트웨어 환경에 있어서, 호스트는 MICROSOFT TM.NET TM 런타임 또는 MICROSOFT TM SILVERLIGHT TM 런타임과 같은 런타임을 포함할 수 있다. 웹 애플리케이션은 또한 애플리케이션 호스트도 포함할 수 있고 다른 서버 또는 데스크톱 컴퓨팅 환경 내에서 구동하는 샌드박스된(sandboxed) 환경에서 실행할 수 있다. 서버 컴퓨팅 시스템은 가상화 하드웨어 또는 소프트웨어를 포함할 수 있고 하나 이상의 운영 시스템 커널보다 더 높은 레벨에서 동작하는 하이퍼바이저(hypervisor)를 포함할 수 있다. 메모리 관리 시스템(100)은 다양한 레벨의 소프트웨어 코드로 구현될 수 있고 따라서 특정 유형의 호스트로 한정되지 않는다. 호스트 구성요소(140)는 애플리케이션과 상호작용하고 시스템(100)이 구동중인 특정 플랫폼에 대한 리소스를 관리하는 책임이 있는 구성요소를 나타낸다.
요청 수신 구성요소(145), 요청 저장 구성요소(150), 할당 구성요소(155) 및 메모리 동작 구성요소(160)는 함께 본 명세서에 기술된 시스템(100)을 구현하도록 수정된 메모리 관리자의 구성요소를 구성한다.
요청 수신 구성요소(145)는 메모리를 할당하라는 요청을 애플리케이션으로부터 수신한다. 각 요청은 애플리케이션이 할당된 메모리를 이용하는 방식을 기술하는 호스트에 정보를 제공하는 메타데이터를 포함한다. 요청 수신 구성요소(145)는 호스트가 메모리가 사용되는 방식을 기술하는 광범위한 범위의 정보를 갖도록 특정 호스트 상에서 구동중인 복수의 또는 모든 애플리케이션으로부터의 요청을 수신할 수 있다. 그 다음 호스트는 특정 동작을 취하라는 결정에 따라 어떠한 할당에 영향을 줄 것인지의 우선순위를 매길 수 있다(예로서, 메모리 압력을 감소시키도록 메모리를 자유화하거나 페이지-아웃(page-out) 한다).
요청 저장 구성요소(150)는 메모리 관리 결정을 하는 동안 차후의 이용을 위해 수신된 요청 및 연관된 메타데이터 정보를 저장한다. 호스트는 요청이 수신된 시간에 할당 요청을 만족시킬 수 있거나 만족시키지 않을 수 있다. 그러나, 호스트가 요청을 즉시 만족시키거나 또는 이후에 만족시키거나, 메모리 동작이 적절할 때 호스트가 후에 이용가능한 정보를 갖도록, 호스트는 할당과 연관된 애플리케이션에 의해 제공된 정보를 저장한다. 일부 실시예에서, 호스트는 애플리케이션이 할당된 메모리를 가진 후에 애플리케이션으로부터 개별적인 통신 내의 메타데이터 및 다른 정보를 수신한다. 이러한 경우에, 호스트는 다수의 시간에 또는 유용한 정보가 이용가능할 때 할당 정보를 저장할 수 있다.
할당 구성요소(155)는 하나 이상의 수신된 애플리케이션 할당 요청을 만족시키도록 메모리를 할당하기 위한 실질적인 동작을 수행한다. 할당 구성요소(155)는 호스트에 액세스 가능하거나 또는 호스트에 의해 관리되는 컴퓨터 시스템 내에 설치된 물리적 메모리로부터 직접 또는 애플리케이션 힙(heap)으로부터 메모리를 할당할 수 있다. 할당 후에, (전형적으로 공유되는 메모리 기술을 통해 요청하지 않는 한) 메모리는 특정 애플리케이션에 전용화되고 다른 애플리케이션에 의해서는 사용될 수 없다. 할당 구성요소(155)는 할당을 위해 윈도우를 물리적 메모리로 제공하도록 가상 메모리 및 페이지 테이블과 작동할 수 있으며, 제공된 메모리는 스왑 파일(swap file)을 통해서 디스크 또는 다른 스토리지에 의해 되돌려질 수 있다.
메모리 동작 구성요소(160)는 디바이스 상의 메모리를 관리하기 위한 동작을 수행하며 수행된 동작에 의해 영향을 받게 될 하나 이상의 적절한 메모리 할당을 결정하도록 앞서 저장된 수신된 요청 정보에 액세스한다. 동작들은 메모리 콘텐츠를 스왑 파일로 교체(swap)하는 것, 앞서 할당된 메모리를 자유화하는 것, 애플리케이션이 자신의 메모리 풋프린트를 감소시키도록 요청하는 것, 또는 하나 이상의 애플리케이션에 의해 사용되는 메모리에 영향을 미치는 임의의 다른 동작을 포함할 수 있다. 전형적으로, 메모리 관리 동작을 수행하는 것에서의 호스트의 목적은, 낮은 메모리(예로서, 메모리 압력), 애플리케이션 수요를 만족시키기 위한 충분한 메모리 수집 등과 같은 현재 또는 임박한 조건을 조절하는 것이다.
데이터 스토어 구성요소(165)는 하나 이상의 애플리케이션 대신 메모리를 관리하도록 호스트에 의해 사용되는 정보를 저장한다. 데이터 스토어 구성요소(165)는 시스템(100), 개별적인 플래시 또는 디스크 스토리지, 또는 데이터를 저장하기 위한 다른 시설에 의한 이용을 위해 남겨둔 메모리를 포함할 수 있다. 데이터 스토어 구성요소(165)는 또한 애플리케이션 대신 메모리를 관리하도록 호스트에 의해 이용되는 다른 정보 및 해당 애플리케이션과 관련된 할당을 추적하는 각 애플리케이션의 메모리 공간 내에 저장된 데이터를 포함할 수 있다.
메모리 관리 시스템이 구현될 수 있는 컴퓨팅 디바이스는 중앙 처리 장치, 메모리, 입력 디바이스(예로서, 키보드 및 포인팅 디바이스), 출력 디바이스(예로서, 디스플레이 디바이스) 및 저장 디바이스(예로서, 디스크 드라이브 또는 다른 비휘발성 저장 매체)를 포함할 수 있다. 메모리 및 스토리지 디바이스는 시스템을 구현하거나 가능케 하는 컴퓨터 실행가능한 명령(예로서, 소프트웨어)으로 인코딩될 수 있는 컴퓨터 판독가능한 저장 매체이다. 또한, 데이터 구조 및 메시지 구조는 통신 링크 상의 신호와 같은 데이터 전송 매체를 통해 저장 또는 전송될 수 있다. 인터넷, 로컬 영역 네트워크, 광역 네트워크, 포인트-투-포인트 다이얼-업 접속, 휴대폰 네트워크 등과 같은 다양한 통신 링크가 사용될 수 있다.
시스템의 실시예들은 개인 컴퓨터, 서버 컴퓨터, 휴대용 또는 랩탑 디바이스, 멀티프로세서 시스템, 마이크로프로세서 기반의 시스템, 프로그램가능한 소비자 전자기기, 디지털 카메라, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 전술된 임의의 시스템 또는 디바이스를 포함하는 분산 컴퓨팅 환경, 셋톱박스, 시스템-온-칩(SOC), 등을 포함하는 다양한 운영 환경에서 구현될 수 있다. 컴퓨터 시스템은 휴대폰, PDA, 스마트폰, 개인 컴퓨터, 프로그램가능한 소비자 전자기기, 디지털 카메라 등일 수 있다.
시스템은 하나 이상의 컴퓨터 또는 다른 디바이스에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능한 명령의 일반적인 맥락에서 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정한 추출 데이터 유형을 구현하는 루틴, 프로그램, 객체, 구성요소, 데이터 구조 등을 포함한다. 전형적으로, 프로그램 모듈의 기능은 다양한 실시예에서 요구되는 것과 같이 결합되거나 분산될 수 있다.
도 2는 일 실시예에서의 메모리 관리 시스템의 운영 환경을 도시한 블록도이다. 환경은 커널/호스트(210), 하나 이상의 애플리케이션(220), 메모리 핸들링 프레임워크(230), 저장된 할당 메타데이터(240) 및 하나 이상의 툴(250)을 포함한다. 커널/호스트(210)는 하나 이상의 애플리케이션(220)에 의해 공유되는 메모리를 관리한다. 메모리 핸들링 프레임워크(230)는 애플리케이션(220)이 메모리를 할당하고 메모리 할당 메타데이터를 제공하도록 호출할 수 있는 하나 이상의 API를 제공한다. 메모리 핸들링 프레임워크(230)는 수신된 메타데이터(240)를 저장한다. 툴(250)은 정적 및 동적 분석을 통해 이러한 정보를 추출하기 위해 본질적으로 할당 정보를 제공하도록 설계되지 않은 애플리케이션 상에서 동작한다. 임의의 추출된 정보는 그 다음 할당 메타데이터(240)로서 저장된다.
시스템 동작
도 3은 일 실시예에서 메모리의 할당 및 이용을 요청하기 위한 소프트웨어 애플리케이션 내의 메모리 관리 시스템의 프로세싱을 도시한 순서도이다.
블록(310)에서 시작하여, 애플리케이션은 애플리케이션이 어떻게 메모리 할당을 이용할 것인지를 기술하는 할당 메타데이터를 설정한다. 애플리케이션은 할당 함수로 전달하기 위한 파라미터 구조를 구축하고, 할당 메타데이터를 제공하기 위한 API를 호출하고, 또는 본 명세서에 기술된 메모리 관리 시스템에 따라 메모리를 할당하기 위해 파생된 클래스의 파라미터를 설정할 수 있다. 할당 메타데이터는 얼마나 자주 애플리케이션이 할당된 메모리를 이용하고자 계획하는지, 애플리케이션이 할당의 콘텐츠 및 애플리케이션의 메모리 이용과 관련된 다른 정보를 대체하는 것이 얼마나 어려운지, 및 복수의 애플리케이션에 의해 공유되는 물리적 메모리 리소스를 효율적으로 이용하기 위해 호스트가 어떻게 메모리를 조작할 수 있는지, 애플리케이션에 대한 메모리의 우선순위 레벨을 포함할 수 있다.
계속해서 블록(320)에서, 애플리케이션은 메모리 할당의 콘텐츠를 채우는 메모리 필링 함수(fill function)를 설정한다. 메모리 필링 함수는 파일로부터의 정보에 액세스할 수 있고, 메모리 할당 내에 저장되는 결과를 생성하도록 하나 이상의 계산을 수행할 수 있고, 또는 메모리 할당을 채우는 다른 동작들을 수행할 수 있다. 할당 직후에 필링 함수를 적용하기보다는 호스트에 메모리 필링 함수를 제공함으로써, 애플리케이션은 필요에 따라 메모리를 해제하고 다시 채우거나, 또는 호스트에 보다 적절한 시간까지 메모리의 초기 포퓰레이션(population) 및 할당을 연기하는 데에 필요한 정보를 호스트에 제공한다.
계속해서 블록(330)에서, 애플리케이션은 복수의 애플리케이션에 걸쳐 공유되는 물리적 메모리를 관리하는 호스트에 의해 제공되는 할당 인터페이스를 적용하며, 이때 애플리케이션은 할당 인터페이스를 통해 호스트에 설정된 할당 메타데이터 및 메모리 필링 함수를 제공한다. 할당 인터페이스는 운영 시스템 API, 런타임 함수, 또는 메모리 관리에 책임이 있는 호스트와 애플리케이션 사이에서 정보를 전달하는 다른 방식을 포함할 수 있다. 할당 인터페이스는 오늘날 메모리 할당에서 전형적으로 제공되는 것보다 더 많은 정보를 제공하며, 컴퓨팅 디바이스 상에서 메모리를 보다 효율적으로 관리하는데에 유용한 호스트 정보를 준다.
계속하여 블록(340)에서, 할당 인터페이스를 적용하는 것에 응답하여 참조(reference)를 수신하며, 이때 참조는 애플리케이션에 의한 추후의 할당된 메모리 사용을 위한 간접적인 식별자로서의 역할을 한다. 호스트는 요청을 수신함에 따라 즉시 할당할 수 있거나 할당하지 않을 수 있다. 또한, 호스트는 애플리케이션이 메모리를 이용하기 전에 호스트가 다시 제어를 수신해야할 필요가 있는 방식으로 가끔 메모리를 수정할 수 있다(예로서, 해제, 디스크에 페이징 등). 따라서, 호스트는 애플리케이션에 메모리에 대한 참조를 제공하며, 애플리케이션이 메모리를 사용하기 원할 때, 애플리케이션은 메모리에 대한 직접적인 액세스를 획득하도록 참조를 제공한다(예로서, 포인터).
계속해서 블록(350)에서, 만약 애플리케이션이 할당된 메모리를 처리하였다는 것을 검출하면 애플리케이션이 완료되며, 그렇지 않다면 애플리케이션은 블록(360)에서 계속된다. 애플리케이션이 완료되기 전에, 애플리케이션은 앞서 할당된 메모리를 할당 해제(또는 자유화)하도록 할당 인터페이스를 적용할 수 있다. 만약 애플리케이션이 메모리를 사용하지 않았고 호스트가 실질적으로 메모리를 할당하지 않았다면, 이러한 동작은 할당과 관련된 호스트의 저장된 엔트리를 간단히 청소하고 제어를 애플리케이션으로 복귀시킬 수 있다.
계속해서 블록(360)에서, 만약 애플리케이션이 애플리케이션 내에서 할당된 메모리의 이용을 검출한다면 애플리케이션은 블록(370)으로 진행되고, 그렇지 않으면 애플리케이션은 메모리 할당 목적의 완료 또는 메모리 액세스를 기다리도록 블록(350)으로 이동한다. 애플리케이션은 메모리가 애플리케이션 소프트웨어 코드 내의 어디에서 액세스 되든 특정한 함수를 호출할 수 있거나 또는 메모리를 이용가능하게 하기 위해 호스트로의 적절한 호출로 메모리의 액세스를 랩핑(wrap)하는 클래스 내의 메모리 할당을 압축할 수 있다.
계속해서 블록(370)에서, 애플리케이션은 호스트로부터의 메모리 할당에 직접 액세스하도록 요청한다. 만약 호스트가 이미 메모리를 할당하였다면, 호스트는 포인터를 메모리가 액세스될 수 있는 애플리케이션으로 반환한다. 만약 호스트가 메모리를 할당하지 않았거나 또는 할당해제되어 메모리를 재사용하였다면, 호스트는 애플리케이션 요청에 응답하여 메모리를 할당하고, 메모리 콘텐츠를 채우도록 수신된 필링 함수를 적용하며, 포인터 또는 애플리케이션에 메모리를 액세스하는 다른 수단을 반환한다.
계속해서 블록(380)에서, 애플리케이션은 호스트로부터 메모리에 대해 수신된 어드레스를 통해 메모리 할당에 액세스한다. 애플리케이션은 메모리를 수정할 수 있고, 메모리로부터 정보를 판독할 수 있고, 또는 다른 전형적인 메모리 동작들을 수행할 수 있다. 애플리케이션이 메모리로의 액세스를 끝냈을 때, 애플리케이션은 호스트에게 메모리를 이용 불가능하게 할 수 있는 관리 동작들을 호스트가 다시 수행할 수 있음을 나타낼 수 있다. 애플리케이션은 만약 호스트가 메모리를 다시 채운다면 메모리가 가장 마지막 변화를 포함하도록 필링 함수에 의해 사용되는 데이터를 업데이트할 수 있다. 블록(380) 후에, 이들 단계들이 종료된다.
도 4는 일 실시예에서 메모리를 할당 및 사용하라는 애플리케이션 요청을 수신하기 위한 호스트 내의 메모리 관리 시스템의 프로세싱을 도시한 순서도이다. 블록(410)에서 시작하여, 호스트는 애플리케이션으로부터 메모리 할당 요청을 수신한다. 호스트는 복수의 애플리케이션으로부터의 요청을 서비스할 수 있고, 호스트 플랫폼 상에서 구동중인 복수의 애플리케이션 중에서 제한된 물리적 메모리를 슬라이스 또는 공유하는 메모리 관리자를 포함할 수 있다. 메모리 할당 요청은, 요청된 메모리 사이즈 또는 요청된 메모리와 관련된 다른 파라미터와 같은 정보를 포함할 수 있다.
계속해서 블록(420)에서, 호스트는 애플리케이션이 요청된 메모리 할당을 이용하고자 계획하는 방식을 명시하는 메모리 할당 메타데이터를 수신한다. 메타데이터는 애플리케이션에 대한 메모리 할당의 중요도 또는 우선순위, 할당이 디스크에 페이징하기에 적합한지 여부, 만약 호스트가 할당을 자유화해야만 한다면 애플리케이션이 메모리의 콘텐츠를 복구할 수 있는지 여부 등과 같은 정보를 포함할 수 있다.
계속해서 블록(430)에서, 호스트는 요청된 메모리 할당의 콘텐츠를 채우기 위해 호스트에 의해 적용될 수 있는 메모리 필링 함수를 애플리케이션으로부터 수신한다. 메모리 할당을 채우는 수단을 갖는 것은 호스트로 하여금 메모리의 할당을 연기할 수 있게 할 뿐 아니라 만약 호스트가 다른 애플리케이션 요청을 만족시키거나 다른 메모리 압력을 해제하기 위해 메모리 할당을 자유화해야할 필요가 있다면 메모리를 복구할 수 있게 한다.
계속해서 결정 블록(440)에서, 만약 요청에 응답하여 호스트가 메모리를 직접 할당할 수 있다고 호스트가 결정하면, 호스트는 블록(450)으로 진행하고, 그렇지 않으면 호스트는 블록(460)에서 계속된다. 호스트는 애플리케이션에게 메모리를 표시한 애플리케이션이 얼마나 중요한지 및 애플리케이션이 얼마나 자주 메모리에 액세스하고자 계획하는지에 기초하여 메모리를 직접 할당할지 여부를 결정할 수 있다. 호스트는 또한 호스트가 구동중인 컴퓨팅 디바이스가 요청시에 얼마나 바쁜지와 같은 다른 요인도 고려할 수 있다.
계속해서 블록(450)에서, 호스트는 호스트에게 이용가능한 물리적 메모리로부터 요청된 메모리를 할당한다. 호스트는 페이지 테이블 또는 애플리케이션이 물리적 메모리에 액세스하는 다른 가상 메모리를 셋업할 수 있다. 종래의 호스트는 애플리케이션 요청에 즉시 응답하여 메모리를 할당하거나 만약 호스트가 요청을 만족시킬 수 없다면 요청을 실패시킨다. 그러나, 메모리 관리 시스템은 메모리 또는 다른 호스트 리소스를 보다 효율적으로 이용하기 위해서 요청을 연기하거나 다른 메모리 관리 동작들을 수행할 수 있다.
계속해서 블록(460)에서, 호스트는 수신된 메타데이터 및 필링 함수와 함께 이후의 할당을 위해 수신된 요청을 저장한다. 호스트는 (더 많은 메모리를 이용가능하게 하는 것과 같은) 메모리 관리 동작이 필요할 때 선택하는 다양한 애플리케이션에 의해 요청되는 메모리의 데이터 스토어를 유지시킬 수 있다. 애플리케이션에 의해 제공되는 메타데이터는 호스트로 하여금 어떤 애플리케이션 및 애플리케이션 내의 할당이 호스트의 메모리 관리 동작에 의해 부정적인 영향을 최소로 받게 될지를 결정하도록 돕는다. 블록(460) 후에, 이들 단계들이 종료된다.
일부 경우에서, 애플리케이션의 개발자는 새로운 운영 시스템 특성을 지원하기 위해 변경할 의지가 없거나 변경하는 것이 불가능할 수 있다. 이러한 경우에, 메모리 관리 시스템은 여전히 메모리 할당에 대한 정보를 발견하기 위해 애플리케이션 바이너리 정보를 분석함으로써 일부 개선된 메모리 관리를 제공하는 것이 가능할 수 있으며, 이는 도 5 및 6을 참조로 하여 추가로 기술될 것이다.
도 5는 일 실시예에서 메모리 할당 정보를 제공하도록 특별히 설계되지 않은 애플리케이션을 분석하기 위한 메모리 관리 시스템의 프로세싱을 도시한 순서도이다.
블록(510)에서 시작하여, 시스템은 애플리케이션에 의해 이루어진 메모리 할당을 기술하는 정보가 이용가능하지 않은 애플리케이션을 검출한다. 애플리케이션은 메모리 관리 시스템에 의해 제공되는 메모리 모델 내에 애플리케이션이 참여하는지 여부를 명시하는 자신의 바이너리 모듈 상의 다른 정보 또는 플래그를 포함할 수 있거나, 또는 다른 표지를 제공할 수 있다. 시스템은 각 애플리케이션에 대한 분석이 오직 한 번만 수행되도록 사전에 결정된 애플리케이션 할당 정보를 캐싱할 수 있다. 따라서, 이러한 단계에서 시스템은 분석이 이전에 수행되지 않았음을 결정한다.
계속해서 블록(520)에서, 시스템은 애플리케이션에 의해 이루어진 메모리 할당을 결정하도록 애플리케이션에 대한 분석을 수행한다. 분석은 애플리케이션의 정적 및/또는 동적 분석의 다양한 형태를 포함할 수 있다. 정적 분석은 애플리케이션을 구동하지 않고도 발생하며 애플리케이션의 행동을 결정하도록 애플리케이션의 바이너리 코드를 점검한다. 동적 분석은 애플리케이션이 구동중일 때 발생하며 애플리케이션의 인-메모리 코드, 데이터 구조 및 애플리케이션의 행동을 결정하기 위한 다른 정보를 점검한다. 시스템은 메모리 할당, 액세스 및 자유화를 위해 특정 호스트 API로의 호출을 찾을 수 있으며, 위치, 서라운딩 보충 정보, 할당된 메모리를 채우도록 사용되는 단계들 등을 인지할 수 있다.
계속해서 블록(530)에서, 시스템은 애플리케이션이 메모리를 할당하는 애플리케이션 내의 위치에서 할당 정보를 제공하도록 애플리케이션을 후크한다. 애플리케이션 바이너리 코드의 방향수정이 프로그램의 임의의 포인트에서 애플리케이션의 정상 행동을 방해하거나 또는 증폭시킬 수 있게 하는 MICROSOFT TM Detours 등과 같이 기술을 후크하는 다양한 형태의 애플리케이션이 이용가능하다. 예를 들어, 시스템은 원래 애플리케이션에 의해 호출된 메타데이터 없이 표준 할당 기능 대신 할당 메타데이터를 제공하기 위해 할당 기능을 적용하는 애플리케이션 후크를 제공할 수 있다.
계속해서 블록(540)에서, 시스템은 후크된 애플리케이션 코드에 의해 제공되는 연관된 할당 정보 및 메모리를 할당하라는 애플리케이션으로부터의 요청을 수신한다. 할당 정보가 할당 정보를 제공하도록 특별히 설계되지 않은 애플리케이션으로부터 올 수 있다고 결정할 수 있는 요청이 호스트에 의해 수신된다. 호스트는 이러한 애플리케이션에 대해서는 시스템과 작동하도록 설계된 애플리케이션과는 다르게 행동할 수 있다. 예를 들어, 호스트는 시스템과 작동하도록 설계되지 않은 애플리케이션에 의해 제공된 잠재적으로 매우 적은 정보를 고려할 수 있다. 일부 실시예에서, 새로운 메모리 모델의 채택을 권장하도록, 시스템은 메모리 압력이 발생하였을 때 다른 메모리 관리 동작들을 수행하거나 또는 데이터를 디스크로 교체하는 것을 선호함으로써 새로운 메모리 모델을 고수하지 않는 애플리케이션을 불리하게 할 수 있다. 블록(540) 후에, 이들 단계들이 종료된다.
도 6은 일 실시예에서 개선된 메모리 정보에 대한 목록을 제공하고 애플리케이션을 정적으로 분석하는 메모리 관리 시스템의 프로세싱을 도시한 순서도이다.
계속해서 블록(610)에서, 시스템은 메모리 할당 함수로의 호출과 관련하여 메모리 할당 정보를 제공하지 않는 컴파일된 애플리케이션 코드를 수신한다. 시스템은 컴퓨팅 디바이스의 하드 드라이브 또는 다른 스토리지의 스캔으로부터의 벌크 프로세싱 동안, 또는 특정 사용자 또는 관리자 요청에 응답하여, 애플리케이션을 구동하라는 첫 번째 요청에 따라 애플리케이션 코드를 수신할 수 있다. 컴파일된 애플리케이션 코드는 특정 프로세서(예로서, x86 또는 x64 바이너리 코드)에 대한 바이너리 코드, 특정 런타임에 대한 중간 언어 코드, 또는 비-소스 애플리케이션 코드의 다른 형태를 포함할 수 있다. 소스가 이용가능한 경우, 애플리케이션은 본 명세서에 기술된 바와 같이 시스템을 이용하기 위해 직접 수정될 수 있다.
계속해서 블록(620)에서, 시스템은 애플리케이션이 메모리를 할당하는 코드 내의 위치를 결정하도록 수신된 애플리케이션 코드에 대한 정적 분석을 수행한다. 정적 분석은 예로서 불러온 모듈 또는 다른 수단을 통해 메모리 할당 함수에 대한 호출을 찾을 수 있다. 정적 분석은 일부 경우에서 전달된 파라미터뿐 아니라 함수에 대한 호출을 찾는데 유리하다. 일부 실시예에서, 시스템은 동적 분석으로 정적 분석을 보강하며, 이용가능하지 않거나 정적으로 쉽게 검출가능한 정보를 식별하도록 애플리케이션을 구동한다.
계속해서 블록(630)에서, 시스템은 분석된 애플리케이션 코드 내의 하나 이상의 메모리 관련 코드 동작들을 식별한다. 코드 동작은 메모리 할당, 메모리 액세스, 메모리 해제 및 다른 메모리 동작들을 포함할 수 있다. 시스템은 동작들이 발생하는 어드레스에 의해서 또는 이후에 호스트에 제공될 수 있거나 디폴트 애플리케이션 행동을 변경하도록 수정될 수 있는 다른 식별에 의해서 코드 동작들을 식별할 수 있다.
계속해서 블록(640)에서, 시스템은 할당된 메모리에 어떻게 애플리케이션에 의해 사용되는지를 기술하는 추가적인 정보를 제공하는 각 식별된 코드 동작과 관련된 서라운딩 정보를 식별한다. 서라운딩 정보는 할당이 얼마나 오랫동안 저장되는지(예로서, 동일한 함수에서 한번 사용되거나 반복되는 후속 이용에 대한 글로벌 변수에서 저장됨), 메모리 할당의 콘텐츠를 채우는 것이 애플리케이션에게 얼마나 쉬운지 등을 시스템에 말할 수 있다. 서라운딩 정보는 정적 및/또는 동적 분석을 통해 식별될 수 있다.
계속해서 블록(650)에서, 시스템은 애플리케이션 구동에 따른 호스트에 의한 후속 검색을 위해 데이터 스토어 내의 임의의 식별된 서라운딩 정보 및 식별된 메모리 관련 코드 동작들을 저장한다. 일부 실시예에서, 애플리케이션을 로딩하는 호스트가 애플리케이션에 의해 이루어진 메모리 할당을 기술하는 호스트로 더 많은 정보를 제공하기 위해 식별된 위치의 후크 또는 방해를 수행할 수 있도록 시스템은 애플리케이션 모듈로 저장된 목록 내의 식별된 정보를 저장한다. 호스트는 예를 들어 분석에 의해 결정되는 바와 같이 시스템이 유휴 중이거나 활용되지 않는 동안 미래에 어떤 시간에서 애플리케이션이 필요로 할 메모리를 선제적으로 할당하기 위해 이러한 정보를 이용할 수 있다. 이는 레거시 애플리케이션이 메모리 관리 시스템에 의해 제공된 메모리 모델에 참여할 수 있게 한다. 블록(650) 후에, 이들 단계들은 종료된다.
도 7은 일 실시예에서 검출된 메모리 압력에 응답하여 메모리와 관련된 동작을 취하기 위한 메모리 관리 시스템의 프로세싱을 도시한 순서도이다. 메모리 압력은 제한된 메모리를 갖는 디바이스가 자신의 이용가능한 메모리에 근접하였을 때 발생할 수 있다. 예를 들어, 시스템의 운영 시스템은 메모리 압력이 물리적 RAM의 90%가 사용되었을 때 발생하는 것으로 정의할 수 있다.
블록(710)에서 시작하여, 시스템은 메모리 할당이 하나 이상의 애플리케이션에 의해 사용되는 방식 및 복수의 메모리 할당 요청을 기술하는 정보를 수신한다. 일부 경우에, 시스템은 각 할당이 사용되는 방식을 기술하는 연관 메타데이터뿐 아니라, 할당의 다른 데이터 구조 또는 리스트가 애플리케이션으로부터 수신됨에 따라 이들을 저장한다. 할당 이용 정보는 우선순위 또는 시스템이 어떤 할당이 자유화되고, 페이징되거나, 또는 이용가능한 메모리를 효율적으로 관리하도록 다른 식으로 조정될 수 있는지 결정하는 것을 도울 수 있는 다른 정보를 포함할 수 있다.
계속해서 블록(720)에서, 시스템은 효율적으로 애플리케이션 구동을 계속할 필요성을 나타내는 메모리 압력을 검출한다. 검출된 메모리 압력은 커널 또는 다른 호스트가 취할 수 있는 동작들 또는 다양한 조건들을 포함할 수 있다. 예를 들어, 커널은 전력을 절약하기 위해서 메모리 뱅크를 스위치-오프 하기를 원할 수 있으며, 해당 뱅크 상에 저장된 할당을 검출하고 뱅크가 스위치-오프될 수 있도록 그러한 할당을 해제 또는 교체할 수 있다. 다른 예시로서, 시스템은 스위치-오프될 수 있는 빈 뱅크를 획득하도록 메모리 뱅크를 디프래그(defragment)할 수 있다. 호스트가 메모리의 이용을 완전히 제어하지 않는 경우에, 종종 애플리케이션 협력 없이 메모리를 이동 또는 해제하는 동작들을 수행하기 어렵다. 그러나, 본 명세서에 기술된 메모리 관리 시스템은 호스트에게 훨씬 더 많은 정보를 허용하며 메모리가 관리되는 방식에 대한 제어를 가능하게 한다.
계속하여 블록(730)에서, 시스템은 동작할 할당을 결정하라는 수신된 할당 요청을 열거한다. 시스템은 자유화가 필요하거나 애플리케이션이 다시 해당 할당을 사용할 가능성이 없다면, 쉽게 복구될 수 있는 할당을 결정하기 위해 리스트 또는 할당의 다른 데이터 구조를 가로지를 수 있다.
계속해서 블록(740)에서, 시스템은 동작할 하나 이상의 열거된 할당을 선택한다. 시스템은 할당을 요청한 애플리케이션에 의해 할당이 사용되는 방식을 기술한 수신된 정보에 기초하여 할당을 선택할 수 있다. 일부 경우에, 시스템은 메모리 관리자의 특정한 목표(예로서, 특정한 메모리의 총 사이즈에 대한 동작 및 해당 사이즈가 되거나 해당 사이즈를 초과하는 할당을 발견)에 의존하여 복수의 할당을 선택할 수 있다.
계속해서 블록(750)에서, 시스템은 메모리 압력을 해제하도록 선택된 할당에 대한 동작을 수행한다. 동작들은 이전에 할당된 메모리를 자유화하는 것, 메모리 콘텐츠를 디스크 또는 다른 스토리지로 교체하는 것, 메모리를 이전의 위치로부터 새로운 위치로 이동시키는 것 등을 포함할 수 있다. 일부 경우에서, 시스템은 애플리케이션에 동작을 알리며, 따라서 애플리케이션은 할당에 의존하는 행동을 수정할 수 있다. 예를 들어, 애플리케이션에 의해 다음에 메모리가 사용될 때 메모리를 재할당함으로써 애플리케이션이 응답할 수 있다. 블록(750) 후에, 이들 단계들은 종료된다.
도 8은 일 실시예에서 메모리가 이전에 호스트에 의해 수정된, 애플리케이션을 활성화하기 위한 메모리 관리 시스템의 프로세싱을 도시한 순서도이다. 다수의 멀티태스킹 시스템에서, 애플리케이션은 백그라운드로 푸시(push)되고 이후에 사용자 또는 운영 시스템에 의해서 재활성화된다. 모바일 디바이스 상에서, 사용자는 한번에 하나의 애플리케이션과 상호작용할 수 있고 운영 시스템은 특정 애플리케이션이 앞에 있는 동안 다른 애플리케이션을 의심할 수 있다. 운영 시스템은 다른 애플리케이션의 메모리를 자유화할 수 있거나 또는 이를 디스크 또는 다른 스토리지로 스트림할 수 있다. 활성화에 따라, 운영 시스템은 애플리케이션을 다시 실행하기 위해 준비하도록 동작할 수 있다.
블록(810)에서 시작하여, 시스템은 활성화하라는 애플리케이션 요청을 수신한다. 요청은 애플리케이션 자신으로부터, 사용자로부터, 또는 운영 시스템으로부터 올 수 있다. 활성화하라는 요청은 애플리케이션이 이전에 할당된 메모리를 요청할 수 있도록 단순히 사용자가 애플리케이션과 다시 상호작용하고 있음을 나타낼 수 있다.
계속해서 블록(820)에서, 시스템은 하나 이상의 이전에 수신된 애플리케이션 메모리 할당을 식별한다. 시스템이 리스트를 가로지름으로써 이전에 수신된 메모리 할당을 식별할 수 있도록, 하나 이상의 할당에 의해 요청된 각 할당의 다른 데이터 구조 또는 리스트를 유지할 수 있다. 시스템은 할당과 관련된 메모리가 여전히 이용가능한지 및 애플리케이션에 의해 이전에 그곳에 배치되었던 콘텐츠를 여전히 포함하는지 여부와 같은 각 할당의 상태를 확인할 수 있다.
계속해서 결정 블록(830)에서, 만약 시스템이 애플리케이션의 할당이 이미 준비되었다고 결정하면 시스템은 블록(860)으로 점프하고, 그렇지 않으면 시스템은 블록(840)으로 진행한다. 시스템은 다른 애플리케이션의 구동과 같은 다른 태스크를 위한 메모리를 제공하도록 애플리케이션 할당에 대한 자유화, 이동, 페이징, 또는 다른 동작을 수행할 수 있다. 따라서, 애플리케이션을 다시 구동할 시간이 되었을 때, 시스템은 할당에 따라 이전에 동작되었던 것을 복구할 수 있거나 또는 애플리케이션이 적절한 동작을 취할 수 있도록 애플리케이션에게 동작을 알릴 수 있다.
계속해서 블록(840)에서, 시스템은 애플리케이션에 의해 예상되는 상태에서 할당을 배치하도록 준비되지 않은 할당을 분배한다. 시스템은 할당을 만족시키기 위해서 이용가능한 물리적 메모리를 할당함으로써 물리적 메모리를 할당에 배정할 수 있다. 일부 경우에서, 시스템은 물리적 메모리 및 교체 파일에 의해 되돌려지는 것과 같은 가상 메모리를 제공할 수 있다.
계속해서 블록(850)에서, 시스템은 애플리케이션에 의해 제공되는 필링 함수를 이용하여 할당된 메모리 콘텐츠를 채운다. 애플리케이션은 시스템이 애플리케이션의 메모리 할당을 해제하고 재생성할 수 있도록 시스템에 충분한 정보를 제공한다. 이것은 시스템으로 하여금 애플리케이션 사이에서 리소스를 공유하는 동시에 애플리케이션에 대한 부정적인 영향을 낮게 유지하기 위한 효율적인 결정을 내릴 수 있게 한다. 이상적으로, 시스템이 메모리 또는 그외의 압력 하에 있을 때, 시스템은 곧 사용될 예정이 아니었던 메모리를 자유화 또는 이동시키고, 다시 이를 필요로 하기 전에 메모리를 복구하기 위한 시간을 갖는다. 종래의 시스템에서, 호스트가 할 수 있는 가장 바람직한 일은 추측하는 것이지만, 본 발명에서의 메모리 관리 시스템을 이용하여, 호스트는 동작이 의존하는 하나 이상의 메모리 할당을 매우 효율적으로 선택할 수 있다.
계속해서 블록(860)에서, 시스템은 요청된 애플리케이션을 활성화하고 애플리케이션에 의해 예상되는 메모리 할당을 애플리케이션에 제공한다. 시스템은 애플리케이션을 위해 메모리를 준비하는 동안 애플리케이션을 중단시킬 수 있고, 그 다음 모든 애플리케이션의 메모리 할당이 준비되었을 때 애플리케이션을 재개할 수 있다. 블록(860) 후에, 이들 단계들은 종료된다.
전술된 내용으로부터, 메모리 관리 시스템의 특정 실시예가 설명을 위해 본 명세서에 기술되었지만, 본 발명의 사상 및 범주로부터 벗어나지 않고 다양한 수정이 이루어질 수 있음이 이해될 것이다. 따라서, 본 발명은 첨부된 특허청구범위에 의해서만 한정된다.

Claims (15)

  1. 메모리 할당 정보를 제공하도록 특별히 설계되지 않은 애플리케이션을 분석하여 상기 애플리케이션으로부터 메모리 할당 정보를 추출하기 위한 컴퓨터에 의해 구현되는 방법으로서,
    상기 애플리케이션에 대한 하나 이상의 분석을 수행하는 단계 - 상기 하나 이상의 분석은 애플리케이션 바이너리 모듈에서의 메모리 관련 행동을 식별하기 위한 정적 분석과 상기 애플리케이션의 런타임 시의 메모리 관련 행동을 식별하기 위한 동적 분석 중 적어도 하나를 포함함 - 와,
    상기 분석의 수행에 기초하여, 상기 애플리케이션이 메모리를 할당하는 상기 애플리케이션 내의 위치에서의 할당 정보를 제공하도록, 상기 애플리케이션을 리다이렉션(redirection) 코드로 수정하는 단계와,
    상기 애플리케이션을 상기 리다이렉션 코드로 수정한 것에 기초하여, 상기 애플리케이션으로부터 메모리를 할당하라는 요청을 수신하는 단계와,
    상기 리다이렉션 코드로부터, 상기 요청의 목적 및 우선순위를 나타내는 할당 정보를 수신하는 단계를 포함하되,
    상기 단계들은 적어도 하나의 프로세서에 의해 수행되는
    컴퓨터에 의해 구현되는 방법.
  2. 제 1 항에 있어서,
    상기 방법은, 상기 애플리케이션이 개선된 메모리 모델에 참여하는지 여부를 명시하는 상기 애플리케이션의 바이너리 모듈 상의 정보를 검출하는 단계를 포함하는
    컴퓨터에 의해 구현되는 방법.
  3. 제 1 항에 있어서,
    상기 방법은, 앞서 캐시된(previously cached) 애플리케이션 할당 정보가 이용가능한지 여부를 결정하는 단계를 포함하는
    컴퓨터에 의해 구현되는 방법.
  4. 삭제
  5. 삭제
  6. 제 1 항에 있어서,
    상기 분석을 수행하는 단계는, 메모리를 할당하거나, 메모리에 액세스하거나, 또는 메모리를 자유화(freeing)하기 위한 하나 이상의 특정한 호스트 애플리케이션 프로그래밍 인터페이스(application programming interface; API)로의 호출을 식별하는 단계를 포함하는
    컴퓨터에 의해 구현되는 방법.
  7. 제 1 항에 있어서,
    상기 분석을 수행하는 단계는 애플리케이션 코드의 메모리 관련 영역 부근의 할당 메타데이터를 식별하는 단계를 포함하는
    컴퓨터에 의해 구현되는 방법.
  8. 제 1 항에 있어서,
    상기 리다이렉션 코드는 상기 애플리케이션의 정상 메모리 관련 행동을 방해하거나 증가시키도록 설정되는
    컴퓨터에 의해 구현되는 방법.
  9. 제 1 항에 있어서,
    상기 리다이렉션 코드는 상기 애플리케이션에 의해 원래 호출되었던 표준 할당 함수 대신 할당 메타데이터를 제공하기 위한 할당 함수를 호출하는
    컴퓨터에 의해 구현되는 방법.
  10. 삭제
  11. 할당 정보를 제공하도록 설계되지 않은 소프트웨어 애플리케이션 내에서의 메모리의 할당 및 이용에 대해 애플리케이션 호스트가 더 많이 제어할 수 있도록 하는 컴퓨터 시스템으로서,
    프로세서 및 메모리를 포함하며, 상기 프로세서 및 상기 메모리는
    각 메모리 할당과 관련되며, 상기 메모리 할당이 얼마나 오래 저장되는지, 상기 메모리 할당이 상기 애플리케이션 호스트에 의해 자유화될 경우 상기 메모리 할당의 콘텐츠가 복구될 수 있는지 및 상기 메모리 할당의 액세스의 빈도가 어떠한지를 기술하는 메타데이터 정보를 수신하고,
    특정 메모리 할당의 콘텐츠가 채워지는 방식을 기술하는 필링 내역 정보를 수신하고,
    메모리 할당 요청을 상기 애플리케이션으로부터 상기 애플리케이션 호스트에 제출하고,
    메모리 할당 관리를 협상하기 위해 상기 애플리케이션과 상기 애플리케이션 호스트 사이에서의 통신 인터페이스를 제공하고,
    상기 애플리케이션이 메모리를 사용하는 방식을 판정하기 위해 애플리케이션 바이너리 또는 다른 애플리케이션 코드에 관한 정적 분석을 수행하고,
    상기 애플리케이션의 메모리 이용과 관련된 추가적인 정보를 수집하기 위해 구동중인 애플리케이션에 대한 동적 분석을 수행하고,
    상기 애플리케이션이 실행되고 상기 시스템에 의해 제공되는 메모리 관리자와 상호작용하는 환경을 제공하도록 실행되는 소프트웨어 명령을 실행하도록 구성되고,
    상기 정적 분석 및 상기 동적 분석의 결과로서, 애플리케이션 메모리 이용 정보가 상기 애플리케이션 호스트에 제공되는
    컴퓨터 시스템.
  12. 제 11 항에 있어서,
    상기 통신 인터페이스는 메모리 할당을 요청하고 상기 할당에 대한 정보를 명시하도록 상기 애플리케이션에 의해 사용되는 베이스 클래스(base class) 또는 하나 이상의 함수뿐 아니라, 상기 애플리케이션에 의해 제공된 사용자-정의된 함수를 이용하여 상기 애플리케이션의 메모리와 상호작용하도록 상기 애플리케이션 호스트에 의해 사용되는 베이스 클래스 또는 함수들도 포함하는
    컴퓨터 시스템.
  13. 제 11 항에 있어서,
    상기 통신 인터페이스는 정적 및/또는 동적 분석에 의해 결정되는 계장화된(instrumented) 애플리케이션 코드 사이의 상호작용을 제공하고, 상기 애플리케이션 호스트와 상호작용하여 할당 정보를 제공하는
    컴퓨터 시스템.
  14. 제 11 항에 있어서,
    상기 정적 분석은 바이너리 코드, 중간 코드(intermediate code), 또는 애플리케이션의 컴파일링되거나 실행가능한 다른 버전을 분석하는 것을 포함하는
    컴퓨터 시스템.
  15. 제 11 항에 있어서,
    상기 명령은, 상기 애플리케이션의 특정한 메모리 관련 동작을 방해하거나 정보를 수신하도록 상기 애플리케이션 바이너리를 계장화하도록 실행되는
    컴퓨터 시스템.
KR1020137033920A 2011-06-20 2012-06-18 수정되지 않은 애플리케이션을 위한 메모리 관리 모델 및 인터페이스 KR101976221B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/163,745 2011-06-20
US13/163,745 US9785470B2 (en) 2011-06-20 2011-06-20 Memory management model and interface for unmodified applications
PCT/US2012/043033 WO2012177577A2 (en) 2011-06-20 2012-06-18 Memory management model and interface for unmodified applications

Publications (2)

Publication Number Publication Date
KR20140033448A KR20140033448A (ko) 2014-03-18
KR101976221B1 true KR101976221B1 (ko) 2019-05-07

Family

ID=47354693

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020137033920A KR101976221B1 (ko) 2011-06-20 2012-06-18 수정되지 않은 애플리케이션을 위한 메모리 관리 모델 및 인터페이스

Country Status (8)

Country Link
US (1) US9785470B2 (ko)
EP (1) EP2721483A4 (ko)
JP (1) JP5980916B2 (ko)
KR (1) KR101976221B1 (ko)
CN (1) CN103635876B (ko)
AR (1) AR086711A1 (ko)
TW (1) TWI539280B (ko)
WO (1) WO2012177577A2 (ko)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9218206B2 (en) 2011-06-20 2015-12-22 Microsoft Technology Licensing, Llc Memory management model and interface for new applications
US8627036B2 (en) * 2011-09-12 2014-01-07 Microsoft Corporation Memory management techniques
JP2014149606A (ja) * 2013-01-31 2014-08-21 Fujitsu Ltd 資源使用量集計プログラム、資源使用量集計方法及び資源使用量集計装置
WO2014186673A2 (en) * 2013-05-17 2014-11-20 Ab Initio Technology Llc Managing memory and storage space for a data operation
US20140372988A1 (en) * 2013-06-14 2014-12-18 Microsoft Corporation Using a Static Analysis for Configuring a Follow-On Dynamic Analysis for the Evaluation of Program Code
EP3017378A4 (en) * 2013-07-05 2017-03-08 Nokia Solutions and Networks Oy Collective over-the -top application policy administration
US9760417B2 (en) 2014-03-10 2017-09-12 Microsoft Technology Licensing, Llc Application dehydration and rehydration during application-to-application calls
US9557917B2 (en) * 2014-11-10 2017-01-31 International Business Machines Corporation Conditional stack frame allocation
US10025747B2 (en) * 2015-05-07 2018-07-17 Samsung Electronics Co., Ltd. I/O channel scrambling/ECC disassociated communication protocol
CN104866237A (zh) * 2015-05-08 2015-08-26 深圳市金立通信设备有限公司 一种终端
KR102303417B1 (ko) * 2015-06-19 2021-09-23 삼성전자주식회사 복수의 운영 체제를 지원하는 전자 장치 제어 방법
GB2554083A (en) * 2016-09-16 2018-03-28 Siemens Rail Automation Holdings Ltd Method for operating a computer, method for controlling a railway network and computer program product
US11194556B1 (en) * 2021-05-11 2021-12-07 Apex.AI, Inc. Deterministic memory allocation for real-time applications

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023712A (en) 1997-07-30 2000-02-08 Quarterdeck Corporation Method and apparatus for brokering memory resources
US20050268064A1 (en) * 2003-05-15 2005-12-01 Microsoft Corporation Memory-usage tracking tool
US20070011658A1 (en) 2005-07-05 2007-01-11 Microsoft Corporation Memory management configuration
US20080163176A1 (en) 2006-12-29 2008-07-03 International Business Machines Corporation Using Memory Tracking Data to Inform a Memory Map Tool
US20080168235A1 (en) 2007-01-07 2008-07-10 Matt Watson Memory Management Methods and Systems

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3574498B2 (ja) 1995-04-27 2004-10-06 富士通株式会社 データ処理装置
JPH10269105A (ja) 1997-01-27 1998-10-09 N T T Data Tsushin Kk トレースシステム、リソース解放漏れ検出システム及び記録媒体
EP1015974B1 (en) 1997-09-25 2001-08-08 BRITISH TELECOMMUNICATIONS public limited company Memory allocation
US6742148B1 (en) 2000-03-06 2004-05-25 Pc-Doctor Inc. System and method for testing memory while an operating system is active
US7036118B1 (en) * 2001-12-20 2006-04-25 Mindspeed Technologies, Inc. System for executing computer programs on a limited-memory computing machine
JP2003241967A (ja) 2002-02-15 2003-08-29 Matsushita Electric Ind Co Ltd プログラム実行装置およびその方法、並びにそこで実行されるプログラム
US20050108562A1 (en) * 2003-06-18 2005-05-19 Khazan Roger I. Technique for detecting executable malicious code using a combination of static and dynamic analyses
US7293259B1 (en) 2003-09-02 2007-11-06 Sun Microsystems, Inc. Dynamically configuring selected methods for instrument-based profiling at application run-time
US8381037B2 (en) * 2003-10-09 2013-02-19 International Business Machines Corporation Method and system for autonomic execution path selection in an application
US7805509B2 (en) * 2004-06-04 2010-09-28 Optier Ltd. System and method for performance management in a multi-tier computing environment
GB2421096A (en) * 2004-12-10 2006-06-14 Hewlett Packard Development Co Determining a memory allocation algorithm in dependence on a memory allocation pattern for a process
US20060149914A1 (en) * 2004-12-30 2006-07-06 Doris Tom F Systems and methods for allocating data structures to memories
US7685588B2 (en) * 2005-03-28 2010-03-23 Intel Corporation Platform independent binary instrumentation and memory allocation method
US7912877B2 (en) 2005-05-20 2011-03-22 Microsoft Corporation Leveraging garbage collection to dynamically infer heap invariants
US7434105B1 (en) * 2005-11-07 2008-10-07 Symantec Operating Corporation Selective self-healing of memory errors using allocation location information
US7552306B2 (en) 2005-11-14 2009-06-23 Kabushiki Kaisha Toshiba System and method for the sub-allocation of shared memory
US7975257B2 (en) 2006-06-13 2011-07-05 Microsoft Corporation Iterative static and dynamic software analysis
US7895579B2 (en) 2006-06-16 2011-02-22 Microsoft Corporation Automated method and system for collecting and reporting API performance profiles
US8812809B2 (en) * 2008-06-10 2014-08-19 Oracle America, Inc. Method and apparatus for allocating memory for immutable data on a computing device
EP2329389A4 (en) * 2008-08-13 2013-02-27 ENHANCING THE PERFORMANCE OF A SOFTWARE APPLICATION

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023712A (en) 1997-07-30 2000-02-08 Quarterdeck Corporation Method and apparatus for brokering memory resources
US20050268064A1 (en) * 2003-05-15 2005-12-01 Microsoft Corporation Memory-usage tracking tool
US20070011658A1 (en) 2005-07-05 2007-01-11 Microsoft Corporation Memory management configuration
US20080163176A1 (en) 2006-12-29 2008-07-03 International Business Machines Corporation Using Memory Tracking Data to Inform a Memory Map Tool
US20080168235A1 (en) 2007-01-07 2008-07-10 Matt Watson Memory Management Methods and Systems

Also Published As

Publication number Publication date
KR20140033448A (ko) 2014-03-18
CN103635876B (zh) 2018-01-02
US9785470B2 (en) 2017-10-10
TW201301033A (zh) 2013-01-01
EP2721483A4 (en) 2016-10-19
WO2012177577A3 (en) 2013-02-21
JP2014523022A (ja) 2014-09-08
AR086711A1 (es) 2014-01-15
CN103635876A (zh) 2014-03-12
EP2721483A2 (en) 2014-04-23
TWI539280B (zh) 2016-06-21
WO2012177577A2 (en) 2012-12-27
JP5980916B2 (ja) 2016-08-31
US20120324197A1 (en) 2012-12-20

Similar Documents

Publication Publication Date Title
KR101936453B1 (ko) 새로운 애플리케이션을 위한 메모리 관리 모델 및 인터페이스
KR101976221B1 (ko) 수정되지 않은 애플리케이션을 위한 메모리 관리 모델 및 인터페이스
EP2721480B1 (en) Memory manager with enhanced application metadata
US11106579B2 (en) System and method to manage and share managed runtime memory for java virtual machine
US9836328B2 (en) System and method for improving memory usage in virtual machines at a cost of increasing CPU usage
US10152409B2 (en) Hybrid in-heap out-of-heap ballooning for java virtual machines
US20230418643A1 (en) Improved memory management for busy virtual machine guests

Legal Events

Date Code Title Description
N231 Notification of change of applicant
A201 Request for examination
E902 Notification of reason for refusal
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant