메모리는 할당하는것보다 해제하는게 더 중요하다.

난 메모리 새는 코드를 짜는 프로그래머는 맞아야 한다고 생각하는 사람이다.

이 얘길 하면 많이들 공감한다.

근데 막상 힙 메모리와 커널 오브젝트를 정말 깔끔하게 해제하기 위해서 어떤 노력을 하고 있는지 물어보면 아무것도 안하는 경우가 많다.

Windows Application 개발의 예를 들면 CRT Heap Check도 안쓰고, Application Verifier도 안쓰고 뭐 기타 다른 방법도 준비되지 않은 상태로 개발하는 케이스를 많이 본다.

참고로 github에 오픈소스로 올라와있는 C++ Azure Storage SDK도 메모리가 샌다. 
코드 안에 CRT Heap Check가 없다.

귀찮아서 그런거지 불편한 진실을 마주하고 싶지 않은건지.

커널 오브젝트 해제가 완벽하게 되고 있는지 확인하는 경우는 더 찾기 힘들다.

힙을 깨먹고 있는 상황에서도 Page Heap을 사용해서 힙을 깨먹는 일이 있는지 체크하는 경우는 더더욱 보기 힘들다.

Page Heap이 뭔지 모르는 경우가 다반사고 알려줘도 사용할 수 없을때가 많다. 작은 사이즈의 메모리 할당/해제가 빈번한데 64비트 모드를 지원하지 않아 Page Heap을 사용할 수 없다.
Page Heap을 사용하면 (메모리 블럭 하나당 4KB 페이지를 사용하므로) 메모리 사용량이 급격히 불어나는데 프로젝트는 32비트밖에 지원을 안해서 일반적인 CRT Heap의 최대 사이즈 1.2GB -1.4GB에 도달하여 할당에 실패하는 것이다.

장담하는데 상당수의 상용 프로젝트들도 CRT Heap Check만 돌려봐도 새는 메모리 꽤 나온다. 커널 오브젝트는 말할것도 없고.

안타까운 현실이다.

거듭 강조한다.
메모리는 할당하는것보다 해제하는게 더 중요하다.

 

<덧붙임>

메모리 해제 얘길 했더니 그걸 C/C++포인터 문제로 접근하는 사람들이 많네. 그 얘기 아님.

C++에서도 ref count를 써서 수동 해제 작업 없이 처리할 수 있다. 그런데 그 얘기가 아니다.

Windows든 Linux든 MacOSX든 OS의 api를 땡겨쓰는 경우 모두 해당되고, DX,OpenGL, Vulkan등 그래픽 API를 사용할때 모두 해당된다.
커널 모드 프로그래밍이라면 말할것도 없고.
(Mac과 iOS는은 절대 그럴일 없다고 하는 사람들 있을지 모르겠는데 코코아 파운데이션 API를 의외로 많이 쓴다. CF접두어의 API들은 대부분 할당과 해제가 쌍으로 이루어져 있다.)

실수를 하지 않도록 조심하자는 것도 아니다. 그 얘기 아.니.다.

디버깅 능력을 얘기하는거다. 디버깅을 위한 환경 구축에 대한 얘기다. 뒤에서 돌아가는 원리를 알고 있는가 하는 얘기다.

거대한 여객기라도 필요하다면 볼트 하나까지 다 풀어서 뜯어봐야 한다. 그렇게 문제를 찾아서 해결하고 다시 원래대로 다 조립해야한다.

소프트웨어 개발에서도 이런게 필요한데 그걸 할 수 있느냐는 얘기다.
내가 만든 소프트웨어라고 하지만 진정 다 뜯어서 어떻게 돌아가는지 추적할 수 있느냐고.
심지어 내 버그가 아니고 컴파일러나 런타임 라이브러리에 버그가 있을지라도 바이너리를 추적해서 원인을 찾아낼 수 있냐는 얘기이다.

 


답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

w

%s에 연결하는 중