자동 메모리 관리 기능이있는 프로그래밍 환경에서 런타임에 OS 메모리 할당 루틴이 얼마나 자주 호출됩니까?

Question

구현은 malloc을 사용하여 객체에 대한 메모리 블록을 미리 할당합니까? 이 블록을 모두 사용하면 추가 메모리가 요청됩니까? 가비지 수집 실행 및 압축이 발생하면 free에 대한 호출을 통해 메모리가 OS로 반환됩니까?

Answer 1

구현체는 malloc을 사용하여 객체에 대한 메모리 블록을 미리 할당합니까?

예. 가장 자주 그들은 연속적인 메모리 블록을 미리 할당하고 그들 자신의 할당 메커니즘을 구현합니다 (예를 들어, 할당 포인터을 기반으로합니다 - 다음 객체의 메모리 주소를 가리 키기 때문에 객체를 할당하면 단순히이 주소를 반환하고 주어진 바이트 수). 이것은 OS 호출에 의존하는 것보다 빠르며 그러한 메모리 영역을보다 잘 제어합니다. 예를 들어 Windows에서 CLR의 경우 이러한 블록을 세그먼트라고하며 VirtualAlloc/VirtualFree 호출을 통해 관리됩니다. 처음에는 대용량 메모리 영역이 이며 예약 된이고 더 많은 페이지가 필요한 경우 은 커밋 된입니다. Malloc (또는보다 일반적인 - Windows의 경우 HeapAPI)은 CLR에서 사용되지 않습니다.

이러한 블록을 모두 사용하면 추가 메모리가 요청됩니까?

예, 더 많은 블록을 만들 수 있지만 처음에는 예약 된 메모리를 커밋 (소비)하여 "내부"로 커질 수 있습니다.

가비지 수집이 실행되고 압축 될 때 메모리는 무료로 통화를 통해 OS로 반환됩니까?

특정 런타임 구현에 따라 다르지만 주 메모리 교정 메커니즘으로 보지 말아야합니다. 압축은 사전 할당 된 메모리 블록 내부에서 작동합니다. 예를 들어 압축 포인터가 압축이 발생한 후 왼쪽으로 다시 이동합니다. 하지만 일반적으로 GC는 더 이상 필요하지 않다고 결정하면 (내부에있는 모든 객체가 회수 된 것처럼) OS로 반환 될 수 있습니다. 그러나 가상 메모리 공간이 매우 제한적인 32 비트 아키텍처에서는 불필요한 메모리 조각화로 이어질 수 있으며 그러한 메모리 블록을 다시 사용하는 것이 더 나은 옵션이었습니다. 64 비트에서 이것은 큰 문제는 아니지만 그 블록을 재사용하는 것은 여전히 ​​좋은 생각 일 수 있습니다.