관련링크 : http://vineetgupta.spaces.live.com/blog/cns!8DE4BDC896BEE1AD!1104.entry

3.13 Compact Framework GC
Compact Framework 2.0 targets Windows CE 5.0. Windows CE 5.0 is designed for embedded systems and hence needs to run on very constrained hardware. This means that the architecture of Windows CE is very different from Mainstream desktop / server Windows NT OS in a big way.

3.13.1 Windows CE Memory Model
1) There are 32 process slots
* Slot zero is reserved for the currently executing app
* So there can only be 31 apps
2) Each app gets 32 MB of virtual address space. This contains
* Code pages of the EXE
* Statics, Globals, etc.
* Stack of each thread
* Heaps allocated by the app
3) Memory allocated outside 32 MB is from the 1 GB High Memory Area
* This memory is global, not private to the app
* All memory mapped files (DLLs, etc.) are loaded here
* VirtualAlloc calls for more than 2 MB allocate here
4) The OS code is loaded in a separate System Code Space (32 MB)
5) For more details see
* Programming Windows CE by Doug Boling
* Effective Memory, Storage and Power Management in Windows Mobile 5.0

WinCE는 꽤나 단순한 메모리 관리 전략을 사용하므로

1. WinCE의 GC는 delete를 했더라도 신속하게 수집하지 못한다.
2. 힙의 목록 공간이 PC에 비해 엄청나게 작다.
3. 프로세스가 종료하더라도 힙이 바로 회수되지 않는다.

따라서 다음과 같은 방법을 권고하고 있다.

1. String같이 변경이 있을 때마다 new, delete가 잦은 객체를 되도록 사용하지 않는다. 문자열 조작을 줄이고 StringBuilder와 같은 단일 버퍼에서 작업하는 방법을 사용한다.
2. 작은 크기의 메모리 블록을 여러개 잡는 것은 힙목록 공간을 낭비한다. 메모리가 남았음에도 힙이 바닥날 수 있다. 큰 크기의 버퍼를 여러 객체가 나눠서 사용하는 것을 권한다.
3. 큰 크기의 메모리 블록을 해제하고 연속해서 할당하면 해제된 공간이 바로 수집되지 않으므로 메모리 부족을 야기할 수 있다. 큰 메모리 블록은 해제하지 말고 재사용할 것을 권한다.
4. Call by Reference는 가비지 컬렉터의 오버해드를 발생시킬 수 있다. 작은 크기의 인수라면 부득이한 경우가 아니면 Call by Value로 전달하는 것을 권한다.
5. 함수내에서 다른 객체의 Reference(특히 클래스간 상속관계을 포함하여)를 많이 사용하면 쓰기 감시의 오버해드가 발생한다. 되도록이면 형변환 하지 않은 const 포인터나 지역에서 선언한 객체를 사용한다.

여하간 WinCE는 메모리 공간도 PC에 비해 턱없이 부족할 뿐더러
가비지컬렉터가 거의 제 구실을 못하므로 힙에서 메모리를 사용할 때 상당한 주의가 필요하다.

왠지 메모리 관리기를 따로 만들어 사용하는 것이 나을듯..
결과적으로 WinCE는 new & delete에 취약하므로
되도록 적게 사용하는 것이 프로그램의 퍼포먼스에 도움이 된다는 내용..

지금 하고 있는 일에서, WinCE상에서 두번째 실행하면 메모리 공간이 모자라서 리소스를 못읽어들이는 문제가 있었는데.. 이상하게도 2~3초 뒤면 메모리 공간이 해제되면서 다시 실행할 수 있게 되는 경우를 발견했다.
즉, 프로그램 종료시에 해제한 대형 메모리들이 프로세스가 아예 종료했음에도 몇초가 지나도록 제대로 수집되지 못하고 있었던 것이다.
결국 메모리 할당이 안되면 1초씩 기다리며 4번 루프를 돌면서 생성해 보고, 종료시에는 2초의 여유를 두며 종료하는 땜질로 마무리했다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.