viewimage.php?id=3dafdf21f7d335ab67b1d1&no=29bcc427b38477a16fb3dab004c86b6fd0548bb7fdb4d15f4b496390cca9d3ae8d35d511db0ca72fa8ff693f52d718a6959de29ab8b47981063eb0e82ab3fb6467


viewimage.php?id=3dafdf21f7d335ab67b1d1&no=29bcc427b38477a16fb3dab004c86b6fd0548bb7fdb4d15f4b496390cca9d3ae8d35d511db0ce37afd97683b51d01ba70d3df9de74ec0b9ea738f9f2da



앞서 memory compaction 을 이야기 했지만,

뭔가 다른 쓰레드 ( Garbage collector ) 가 임의로 메모리를 정리해 버린다는건,

내가 이미 할당해서 변수에 저장한 메모리 주소의 내용이 나도 모르는 사이 다른 주소로 옮겨져 버린다는걸 의미해.


그래서 주소가 아닌 handle 개념이 도입되게 되고,

주소 그자체의 개념인 포인터가 사라질 수 밖에 없어지는거지.

그게 Java 와 C# 의 특징이야. ( C#에는 locking 해서 접근하는 약간의 융통성이 있지만 )

그렇게 자원을 우회해서 접근하면 성능이 떨어지게 되지. 얼마나? 보통 2배 느려짐.

거기다 쓰레드가 돌게 되니까 보통은 5배 느려짐. 물론 CPU 가 아닌 VM 위에서 해석해 도는 비용도 포함.

이도 저도 다 빼고 미친듯 최적화 해 버리면 Java 꼴이 Java 꼴이 아니게 되어버리지. 안습.

그래봐야 C 보다 느릴 수 밖에 없지만.


handle 이란 개념은 ( 보다 안전하고, 적은 힘을 들여 대상을 다룰 수 있는 매개체 의 개념이야 )

십자드라이버의 손잡이나, 자동차의 핸들을 상상하면 적당해.

그게 컴퓨터에서는 간단히는 정수->주소 형태의 테이블로 구현이 되지.

그러니까 Java like 한 언어에서는 내부적으로 자원1, 자원2 라는 핸들 ( 숫자 ) 단위로 사용할 자원을 명시하고,

Garbage Collector 가 그 해당 자원 번호가 어느 주소를 가리킬지를 변경하고 있다고 보면 되는 것.


전역으로 할당한 큰 메모리, 혹은 heap 에 할당한 더 큰 메모리에

memory pool 형태로 가공해서 접근하는데는 여러가지 노력이 들어.

가장 크게는 자잘한 메모리는 자잘한 메모리끼리, 큰 메모리는 큰 메모리끼리 격리해서 관리하는 것이지.

어쨌든, 남은 메모리는 많은데 쥐도새도 모르게 조금 큰 메모리를 할당할 수 없어지는 단편화문제는 벌어지지 않게 할 수 있고,

할당 해제 비용자체를 OS가 관리해주는 것에 비해 가볍게 줄일 수 있는게 memory pool 의 장점이야.

엄마 병따주세요 하고 엄마한테 음료수 병 주고 따주면 먹는것 보다 내가 따는게 빠르잖아?


전역( static 영역 )을 크게 잡을지 heap 을 크게 잡을지는 실행파일을 만들때 컴파일러에서 설정할 수 있는데


[ Static ][ Heap ][ Stack ]


과 같은 순서로 데이타 영역에 할당이 돼.

보통 기본 옵션으론 ( Windows VCC, BCC )

Stack ( 지역변수가 할당되는 공간 )이 가장 작고,

Static ( 전역변수가 할당되는 공간 )이 그 다음,

Heap ( 동적 할당시 사용되는 공간 ) 이 제일 큰 식이야.

( 운영체제와 컴파일러에 따라 크기와 순서는 다름 )


그러니, 전역 메모리는 메모리 활용도가 떨어진다. 메모리를 많이 차지한다. 라는건 방법론으로 해결될 수 있다는 이야기지.

오히려 처리 속도를 증가시키기 위해선 적극적으로 써 줘야 되는 경우가 많아.


다음 글에서 더 알아보자.