Windows CE 메모리 아키텍처 및 관리 서진호 (JinHo.Seo@microsoft.com) MSDN Seminar for Mobile/Embedded Developers Windows CE 메모리 아키텍처 및 관리 서진호 (JinHo.Seo@microsoft.com) Embedded Developer Evangelist Microsoft

Agenda Windows CE 운영체제의 정의 Windows CE 아키텍처 슬롯 기반 메모리 모델 DLL 로딩 시 이슈 프로세스와 쓰레드 메모리 모델 슬롯 기반 메모리 모델 DLL 로딩 시 이슈 관리형 응용 프로그램 에서의 메모리 관리

Windows CE 운영체제 Small Tiny Kernel. Pocket PC는 ROM 32 MB. Modular 모든 바이너리 파일은 컴포넌트로 구성되어 있고, Registry 로 환경 설정 함. Portable WinCE API로 응용 프로그램과 디바이스 드라이버 Compatible 데스크탑 코드에서 서로 다른 CPU의 Windows CE로 포팅이 가능함. Connected IrDA 나 블루투스 와 같은 PAN(Personal Area Network) USB 나 이더넷 카드와 같은 LAN(Local Area Network) Dial-up 또는 802.11X와 같은 WAN(Wide Area Network) Real time 값을 계산하거나, 지정한 시간에 일정한 데이터를 주는 것과 같이 실시간으로 데이터를 주고 받음.

COREDLL, WINSOCK, OLE, COMMCTRL, COMMDLG, WININET, TAPI Windows CE 아키텍처 응용 프로그램 Embedded Shell Remote Connectivity Windows CE Shell Services Win32 APIs COREDLL, WINSOCK, OLE, COMMCTRL, COMMDLG, WININET, TAPI Network Kernel Library Graphic, Windowing, Event Subsystem Device Manager File Manager IrDA Blue Tooth TCP /IP OAL Bootloader Drivers Device Drivers File Drivers OEM Hardware

Windows CE Kernel의 주요 특징 Multiple Process 최대 32 개의 구분된 Process 를 지원한다. 하나의 프로세스가 가상 32 메모리를 사용한다. Multiple Thread 256 가지 Thread 우선 순위를 지원한다. Fibers 응용 프로그램 수준에서 스케쥴링을 수행하는 작은 단위의 job 이며, 특정한 Quantum 내에 시간을 가지고 있음. 동기화 객체 Critical Sections Mutexes 메모리 모델 Paged

프로세스와 쓰레드 프로세스 – 윈도우CE의 인스턴스 쓰레드 – 윈도우CE에서 모듈을 실행시키는 최소의 단위 CreateProcess – 메모리를 할당하고 리소스를 점유하면서 프로그램 실행 찾는 위치 - \windows, \PPSHELL, 쓰레드 – 윈도우CE에서 모듈을 실행시키는 최소의 단위 프로세스가 생성되면 자동적으로 Primary Thread 가 생성되어 윈도우CE 스케쥴러 에게 병렬적으로 처리하도록 지시 Kernel Mode – 운영체제의 모든 리소스를 접근함. User Mode – ISR(Interrupt Service Routines), 마우스 또는 키보드 이벤트, 응용 프로그램 드라이버

Windows CE 스케쥴러 CE 스케쥴러 – 선점형 Task, 쓰레드를 실행하는 우선순위 기반하는 Time-Slice형 스키마를 사용함. 각 쓰레드는 기본적 Time-Slice를 얻거나 0.1 초 마다 발생되는 Thread Quantum 얻는다. 멀티 쓰레드 일 경우에는 쓰레드가 첫번째의 우선 순위를 가지고 있는 지 판별하려는 round-robin 메커니즘 적용. 쓰레드는 저급 우선순위를 실행하기 전에 높은 우선 순위를 실행하는 데, 높은 우선순위를 Time Critical Property 라고 함. (ISR)

Real Time의 정의 Real Time Hard Real Time Soft Real Time Latency 지정된 시간 안에 명시한 데이터 혹은 장치 컨트롤이 가능한 시스템 Hard Real Time 지정된 시간 내에 동작하지 않은 치명적인 오류, 확실하게 Response 해야 함. Soft Real Time 지정된 시간을 벗어나도 무방한 상황 Latency 요청에 대한 답변 지연 시간을 말함.

Process 관리 최대 32개의 제한된 프로세스를 지원한다. Windows NT와 동일한 방법으로 프로세스 생성 32 비트(DWORD)로 표현되는 환경 Multi Process 환경 아래에서 Multi Thread를 사용하는 모바일 임베디드 환경 Windows NT와 동일한 방법으로 프로세스 생성 콘솔 응용 프로그램 지원

메모리 모델 메모리 모델은 물리적 메모리와 가상 메모리가 있다. 시스템 메모리 맵 응용 프로그램 메모리 맵 가상 메모리 공간은 33 슬롯으로 구성된다. 하나의 프로세스는 하나의 슬롯을 사용한다. Slot 0은 현재 동작중인 Thread의 Process를 나타냄. 응용 프로그램 메모리 맵 32 MB의 제한된 공간을 사용함. 0번지를 기준으로 배치됨. 단, 첫번째 64K 공간은 예약됨.

Windows CE 주소 공간 Not Used 512M Non-Cached 512M Cached 4 GB Not Used Accessable via MmMapiIoSpace 3 GB 512M Non-Cached 2G-3G 이상 물리적 메모리 매핑 0xA0000000 512M Cached 가상 주소 공간 2 GB 0x80000000 Memory mapped files Slot 32 Slot 32 64 MB Slot 1 32 MB Slot 0 64 KB NULL pointers

가상 주소 공간 Kernel Mode Space User Mode Space 커널 모드에서만 접근 가능 사용자 및 커널 모드 FFFF FFFF Kernel Mode Space 커널 모드에서만 접근 가능 8000 0000 User Mode Space 사용자 및 커널 모드 둘 다에서 접근 가능 0000 0000

가상 메모리 가상 메모리 관리 가상 메모리 사용하기 로컬 힙 사용하기 스택 사용하기 Memory Mapping (Shared) Reserved Slot 32:Process32 . Slot 1:Process1 Slot 0:Active Process 2GB 32MB 가상 메모리 관리 Windows CE .NET는 모든 응용 프로그램에 대하여 4GB 가상 공간을 가진다. 가상 메모리 사용하기 메모리의 큰 블록 단위로 할당하기 fragment 할 필요가 없다. Windows CE는 64 KB 블록으로 가상 메모리를 관리한다. 로컬 힙 사용하기 Windows CE 는 응용 프로그램을 위하여 가상 메모리를 예약함. 스택 사용하기 하나의 함수에서 참조하는 변수를 위한 저장 공간 지역

Windows CE 메모리 아키텍처 Windows CE 는 통합하여 4 기가 가상 메모리 주소 공간을 사용한다. 주소 공간은 커널 및 사용자 모드 등 두 개의 공간으로 나누어진다. Kernel 모드는 전체 주소의 공간을 접근할 수 있다. User 모드는 저급 2 기가 바이트만 접근할 수 있다.

Windows XP 메모리 맵 시스템 예약 (kernel 모드 공간) Active Process Active Process FFFF FFFF 시스템 예약 (kernel 모드 공간) Active Process Active Process Active Process 8000 0000 Active Process Active Process 응용프로그램 공간 0000 0000

Windows CE 메모리 맵 시스템 예약 (커널 모드 공간) 용량이 큰 메모리 공간 (메모리 맵 파일) 예약 FFFF FFFF 시스템 예약 (커널 모드 공간) 8000 0000 용량이 큰 메모리 공간 (메모리 맵 파일) 4200 0000 예약 0400 0000 Active Process Active Process 응용프로그램 공간 Active Process Active Process Active Process Application Space Active Process 0000 0000

사용자 가상 공간 Large Memory Area 2 기가 바이트 64, 32 메가 바이트 나눔 LMA를 위한 30개 슬롯 리소스 전용 DLL (63개 슬롯) 8000 0000 2 기가 바이트 64, 32 메가 바이트 나눔 LMA를 위한 30개 슬롯 응용 프로그램에 대한 31 개 슬롯 현재 응용 프로그램에 대한 2 개의 슬롯 1 개 리소스 슬롯 Large Memory Area (memory mapped files) 4200 0000 응용 프로그램 슬롯 (2-33 슬롯) 현재 응용프로그램 (0-1슬롯) 0400 0000 0000 0000

시스템 메모리 맵 메모리 공간은 33 개의 슬롯으로 나누어진다. 슬롯 당 하나의 프로세스가 존재한다 0개 슬롯은 활성화된 프로세스를 포함하고 있다 공유 또는 예약 메모리에 대한 기억을 가지고 있어라.

DLL Space (모든 응용 프로그램 제약조건) 응용 프로그램 메모리 맵 03FF FFFF COREDLL.DLL 다른 ROM DLLs DLL Space (모든 응용 프로그램 제약조건) ROM DLL 공간 0200 0000 non-ROM DLLs Free virtual space Stack (reserved space) 응용 프로그램 지정한 공간 Heap (reserved space) Resources Read write data Read only data Code 0001 0000 0000 0000 reserved

응용 프로그램 메모리 맵 응용 프로그램 공간 - 64 메가 바이트 32 메가 이상으로 매핑 된 DLL DLL 정적 데이터 저급 32M에 매핑됨 EXE 코드, 힙, 스택 및 RAM DLL은 저급 32 메가를 사용한다 32M 이상으로 메모리를 할당하기 위한 응용 프로그램 방법은 없다.

메모리 아키텍처 문제점 32 메가는 크지 않다. DLL는 틀림없이 시스템의 유일한 주소 공간을 가지고 로드 된다. 응용 프로그램 코드 및 데이터 응용 프로그램에 로드 된 DLL DLL는 틀림없이 시스템의 유일한 주소 공간을 가지고 로드 된다. Windows CE 는 전체 시스템에서 유일한 주소 공간의 모든 DLL를 가진다. XIP 영역 사이의 차이점은 로딩된 DLL를 위한 Windows CE로 사용한다.

Box 에서 살기 32 메가 가상 공간의 한도 내에서 프로세싱 하기 이것이 문제인가? 어디서? 가상 할당 용량이 큰 LDA에서 할당

VirtualAlloc 기반 메모리 할당 함수는 다음과 같다 파라미터 lpAddress 커밋 주소 dwSize 블록 크기 flAllocationType MEM_RESERVE, MEM_COMMIT flProtect 보호 플래그 LPVOID VirtualAlloc (LPVOID lpAddress, DWORD dwSize, DWORD flAllocationType, DWORD flProtect);

가상 메모리 프로세스 당 최대 32 메가 주소 공간 페이지 기반의 할당 가상 메모리는 64K 영역 내에 예약한다 여러분은 메모리 맵 개체를 사용함으로써 가상 메모리를 얻을 수 있다. 페이지 기반의 할당 가상 메모리는 64K 영역 내에 예약한다 큰 블록을 예약하고 나서 나중에 커밋 한다

가상 메모리 공간의 한계점 응용 프로그램들은 가상 메모리 공간의 한계점에 대해 고려할 필요가 있다. NT 응용 프로그램은 2 기가 바이트를 가진다 CE 응용 프로그램은 오로지 32 메가에서만 동작한다 기억: 가상 메모리는 64K 영역 내에서 저장된다. int i; PBYTE pMem[512]; // Allocate 512 pages with one call each allocation for (i = 0; i < 512; i++) { pMem[i] = (PBYTE)VirtualAlloc (0, PAGESIZE, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE); }

가상 메모리 공간의 한계점 솔루션: 큰 용량에서 가상 메모리를 예약하라... 또는 메모리 맵 개체를 사용하라 …그리고 나서 필요한 만큼 사용 후 나중에 커밋 하라 또는 메모리 맵 개체를 사용하라 프로세스 슬롯에 존재하지 않는다. int i; PBYTE pBase, pMem[512]; pBase = (PBYTE)VirtualAlloc (0, 512*PAGESIZE, MEM_RESERVE, PAGE_READWRITE); for (i = 0; i < 512; i++) { pMem[i] = (PBYTE)VirtualAlloc (pBase[PAGESIZE * i], PAGESIZE, MEM_COMMIT, PAGE_READWRITE); }

용량이 큰 가상 메모리 할당 Windows CE 는 용량이 큰 (> 2 메가) 메모리는 VirtualAlloc 호출을 요구한다. 공간 32M 박스 밖에서 할당한다. 메모리 맵 개체에 의해 사용되는 똑같은 “공유” 메모리 공간 블록은 다른 응용 프로그램으로 부터 보호를 받을 수 없다. 할당은 반드시 예약하고 나서 나중에 커밋을 해야 한다.

대용량의 가상 할당 Large Memory Area Active Process Active Process FFFF FFFF 8000 0000 Large Memory Area Large VAllocs 여기에 할당 4200 0000 0400 0000 Active Process Active Process Application Space Active Process Active Process Active Process Application Space Active Process 0000 0000

DLL 로딩 포지셔닝 Windows CE는 DLL이 어떻게 메모리에 존재하는 지에 대해 규칙을 가진다. 이러한 규칙들은 불확실한 문제를 야기 시킨다…

DLL 로딩 포지셔닝 DLLs DLLs DLLs DLL A DLL A DLL A DLL B DLL C DLL D DLL C Stack Stack Heap Heap Stack Heap Code Code Code 0000 0000

DLL 로딩 포지셔닝 DLL 로드 주소 공간은 시스템에서 로드 된 모든 문제에 의존적이다. open 시스템에서 어떠한 문제가 발생할 지에 대해 예측을 할 수 없다. DLL은 64K 영역 내에서 로드 된다. 좀 더 많은 DLL들이 시스템에 존재하면 많은 문제가 발생한다. 다중 XIP 영역의 오용은 문제를 더욱 더 악화 시킨다.

다중 XIP 영역 예약 첫번째 XIP 영역 XIP 영역 2 첫 로드 된 XIP 영역 3 주소 OS DLLs DLL A Stack Stack Heap Heap Code Code

다중 XIP 영역 시스템은 첫번째 영역의 위로 부터 마지막 부분의 아래까지 예약한다 DLL을 사용자 마음대로 위치 시킬 수 없다. Windows Mobile 5.0 이전의 시스템은 다중 XIP 영역을 사용한다.

DLL 문제 해결책 몇 개의 DLL DLL 크기는 64K 영역 아래에 다중적으로 존재한다. 영역이란 것은 중요하다. .DLL 로 부터 .EXE 로 코드를 옮겨라 지정한 순서 대로 DLL들을 로드 하기 큰 EXE를 가지는 것은 첫번째로 DLL를 로드하는 것

Windows Mobile 5.0 더 이상 XIP 영역을 의존하지 않는다. 이것은 문제를 해결했다. 새로운 Windows CE 6.0 – Yamazaki 에서 프로세스 및 메모리 공간 사용법이 변한다.

Kernel DLL Kernel DLL들은 매우 강력하다 커널 프로세스 공간 안으로 DLL을 주입하다 새로운 정보를 정렬하는 접근을 가진다 이것은 수많은 도구를 동작시킨다. CeLog Shim Engine Profiling (5.0) KCover

Kernel DLL 기본 Win32 API와 링크를 하지 마라 LibMain 의 포인터 에서 ‘reserved’ 파라미터는 KernelLibIoControl 를 포인트 시킨다. BOOL KernelLibIoControl (HANDLE hModule, DWORD dwIoControlCode, LPVOID lpInBuf, DWORD nInBufSize, LPVOID lpOutBuf, DWORD nOutBufSize, LPDWORD lpBytesReturned );

Windows CE Application With Platform Builder 5.0

관리형 코드 관리형 응용 프로그램은 슬롯 안에서 동작한다. 메모리는 슬롯 안에 할당된다. 아주 큰 용량이 할당도 아무런 문제가 없다

관리형 코드 관리형 코드는 요구된 DLL를 로드 한다. Native DLL 들은 Win32 DLL로 취급한다 런타임에 의해 데이터를 로드 하지 않는다.

세션 요약 32/64 MB 한계 DLL 로드 이슈 관리형 프로세스들은 여전히 한계성을 가진다. 이 문제는 향후 풀려서 나올 것으로 기대된다. DLL 로드 이슈 이전 장치에서는 문제가 발생할 소지가 있다. 관리형 프로세스들은 여전히 한계성을 가진다. 슬롯 안에 할당된 메모리

참고자료 My Blog: http://blogs.msdn.com/jinhoseo MSDN Online Web Site Mobility http://msdn.microsoft.com/mobility Embedded http://msdn.microsoft.com/embedded MVP & Channel Partner Community http://www.mobilemagpie.net http://wecom.dstcorp.com/ http://www.yespartner.com/kr/index.asp

© 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.