CustomAllocator] 4단계_StompAllocator_1

이 글은 [인프런-게임서버 만들기 by rookiss]를 내용을 토대로 개인적으로 학습한 내용을 종합하여 정리 했습니다.

 

 

필요한 이유

메모리 이슈를 디버깅 시점에 수월하게 잡기 위함.

 

메모리 이슈 사례 몇 가지

- dangling pointer  =>스마트 포인터로 어느 정도 해결 가능

 

- user after free  =>스마트 포인터로 어느 정도 해결 가능

 

- 컨테이너 순회 중에 컨테이너 요소를 삽입/삭제하거나 컨테이너를 clear하는 등의 동작을하고 반복문을 빠져 나오지 않는 경우 => 컴파일러가 주기도 하지만 모든 상황에 그럴거란 보장은 없음

 

- casting 문제 상속관계 객체를 잘못 캐스팅 한 경우(일종의 overflow) => dynamic 캐스팅을 하면 좀더 안전하지만 속도 문제로 dynamic 캐스팅을 안 쓰기도 함

 

 

페이지 확인 하는 함수

	SYSTEM_INFO info;

	::GetSystemInfo(&info);

	// 페이지 사이즈. (4kb, 0x1000)
	// 페이지 보다 더 작은 사이즈의 메모리를 운영체제에게 요구해도
	// 운영체제는 페이지 사이즈를 예약합니다.
	info.dwPageSize; 

	// 프로세스 주소 공간에서 특정 영역을 예약할 때 사용하는
	// 단위의 크기, 대부분 65536 값을 가지고 있다.
	info.dwAllocationGranularity;

 

운영체에게 직접 메모리 할당/해제를 요청 하는 법

	int* test = (int*)::VirtualAlloc(NULL, 4, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
	*test = 100;
	::VirtualFree(test, 0, MEM_RELEASE);

 

 

이렇게 했을 때 malloc, free를 이용해서 메모리 할당/해제를 했을 때 무슨 차이가 있을까? VirutualFree()가 호출되고 다시 '*test=200'과 같은 코드가 있으면 크래쉬가 난다. 이전에 new, delete를 사용할 때 발생하는 dangling pointer 이슈 생기지 않는다. 이 말은 new / delete 키워드를 쓰면 운영체제에게 직접 메모리 할당 / 해제 요청을 하는 게 아니라 컴파일러 자체적으로 최적화가 이루어 지고 있을 수 추측할 수 있다. 이런 최적화가 있기 때문에 앞으로 다룰 메모리풀링이 어쩌면 의미가 없을 수도 있다. 하지만 반대로 이런 최적화는 디버깅 단계, 개발 단계에서는 오히려 버그를 찾기 힘들게 한다. 따라서 stomp allocator의 핵심은 직접 운영체제에게 메모리 할당/해제 요청을 함으로써 잘못된 메모리 참조로 인한 이슈를 찾기 위함이다. 3,4단계 포스팅을 통해 stomp allocator의 필요성과 구현을 위한 사전지식을 학습 했으므로 다음 단계에서 직접 구현 해보도록 하자.