D 가비지 수집기가 작동합니까?

Question

그래서 Windows에서이 프로그램을 실행하여 D 가비지 수집기가 제대로 작동하는지 테스트하려고했습니다.

DMD 2.057 및 2.058 베타 모두 내가 -release, -inline, -O을 지정 여부에 관계없이 동일한 결과를 제공 등

코드 :

import core.memory, std.stdio; 

extern(Windows) int GlobalMemoryStatusEx(ref MEMORYSTATUSEX lpBuffer); 

struct MEMORYSTATUSEX 
{ 
    uint Length, MemoryLoad; 
    ulong TotalPhys, AvailPhys, TotalPageFile, AvailPageFile; 
    ulong TotalVirtual, AvailVirtual, AvailExtendedVirtual; 
} 

void testA(size_t count) 
{ 
    size_t[] a; 
    foreach (i; 0 .. count) 
     a ~= i; 
    //delete a; 
} 

void main() 
{ 
    MEMORYSTATUSEX ms; 
    ms.Length = ms.sizeof; 

    foreach (i; 0 .. 32) 
    { 
     testA(16 << 20); 
     GlobalMemoryStatusEx(ms); 
     stderr.writefln("AvailPhys: %s MiB", ms.AvailPhys >>> 20); 
    } 
} 

출력이었다

AvailPhys: 3711 MiB 
AvailPhys: 3365 MiB 
AvailPhys: 3061 MiB 
AvailPhys: 2747 MiB 
AvailPhys: 2458 MiB 
core.exception.OutOfMemoryError 

delete a; 문을 주석 처리하지 않은 경우 출력은

AvailPhys: 3714 MiB 
AvailPhys: 3702 MiB 
AvailPhys: 3701 MiB 
AvailPhys: 3702 MiB 
AvailPhys: 3702 MiB 
... 

그래서 분명히 ... GC가 실제로 작동합니까?

Answer 1

이것은 회귀와 같습니다. D1에서는 발생하지 않습니다 (DMD 1.069). 데이빗 심차 (David Simcha)는 최근에 GC를 최적화 했으므로 이와 관련이있을 수 있습니다. 버그 보고서를 제출하십시오.

Answer 2

작동하지 않습니다. 현재의 구현은 결코 메모리를 운영 체제로 릴리스하지 않습니다. GC가 메모리를 다시 사용하기는하지만 실제로 누수가 아닙니다.

Answer 3

P. 메이크 파일에서 DFLAGS를 -debug=PRINTF으로 설정하여 Druntime을 다시 작성하면 GC가 콘솔을 통해 할당/할당 해제 할시기에 대한 정보를 얻게됩니다. :)

Answer 4

여기의 문제는 잘못된 포인터입니다. D의 가비지 컬렉터는 보수적인데, 이는 포인터가 무엇인지, 그렇지 않은지 항상 알 수는 없다는 것을 의미합니다. 포인터로 해석되는 경우 GC 할당 메모리를 가리키는 비트 패턴이 포인터라고 가정해야합니다. 큰 블록은 잘못된 포인터에 대한 더 큰 목표이기 때문에 이것은 대용량 할당의 경우 주로 문제입니다.

testA()에 전화 할 때마다 약 48MB를 할당하고 있습니다. 필자의 경험으로 볼 때 32 비트 시스템에서 블록에 잘못된 포인터가 있다는 것을 보장하기에 충분합니다. 64 비트 주소 공간이 훨씬 희소하기 때문에 64 비트 모드 (Linux, OSX 및 FreeBSD에서 지원되지만 Windows는 지원하지 않음)로 코드를 컴파일하면 더 나은 결과를 얻을 수 있습니다.

내 GC 최적화 (저는 CyberShadow가 언급 한 David Simcha입니다)에는 두 개의 배치가있었습니다. 하나는 6 개월 이상 지속되어 아무런 문제가 발생하지 않았습니다. 다른 하나는 여전히 풀 요청으로 검토 중이며 아직 주 대기 시간 트리에 포함되어 있지 않습니다. 이들은 아마도 문제가되지 않습니다.

단기적으로 해결책은 이러한 거대한 블록을 수동으로 해제하는 것입니다. 장기적으로, 적어도 힙에 대해서는 정밀한 스캐닝을 추가해야합니다. (정확한 스택 스캐닝은 훨씬 어려운 문제입니다.) 저는 몇 년 전에이 작업을 수행하기위한 패치를 작성했지만 템플릿과 컴파일 시간 함수 평가에 의존하여 각 데이터 유형에 대한 포인터 오프셋 정보를 생성하기 때문에 거부되었습니다. 잘하면이 정보는 결국 컴파일러에 의해 직접 생성되며 가비지 수집기에 대한 정확한 힙 스캔 패치를 다시 만들 수 있습니다.