소스 코드에서만 메모리 할당 해제 시점을 정적으로 예측할 수 있습니까?

메모리 (및 리소스 잠금)는 프로그램 실행 중 결정적인 지점에서 OS로 반환됩니다. 프로그램 자체의 제어 흐름은 주어진 리소스를 할당 해제 할 수있는 위치를 알기에 충분합니다. 인간 프로그래머가 fclose(file)프로그램을 수행 할 때 작성 위치를 알고있는 것처럼.

GC는 제어 흐름이 실행될 때 런타임 중에 직접 파악하여이 문제를 해결합니다. 그러나 제어 흐름에 대한 진실의 근원은 근원입니다. 따라서 이론적으로 free()소스 (또는 AST)를 분석하여 컴파일 전에 호출 을 삽입 할 위치를 결정할 수 있어야합니다 .

레퍼런스 카운팅은이를 구현하는 확실한 방법이지만, 포인터가 여전히 참조 (아직 범위 내)이지만 더 이상 필요하지 않은 상황이 발생하기 쉽습니다. 이것은 포인터를 수동으로 할당 해제하는 책임을 해당 포인터에 대한 범위 / 참조를 수동으로 관리하는 책임으로 변환합니다.

프로그램 소스를 읽을 수있는 프로그램을 작성하는 것이 가능해 보입니다.

1. 프로그램 제어 흐름의 모든 순열을 예측하여 프로그램의 실시간 실행을 보는 것과 유사한 정확도
2. 할당 된 자원에 대한 모든 참조를 추적
3. 각 참조에 대해 참조가 절대 역 참조되지 않는 가장 빠른 지점을 찾기 위해 전체 후속 제어 흐름을 통과합니다.
4. 이 시점에서 해당 소스 코드 줄에 할당 해제 문을 삽입하십시오.

이 작업을 이미 수행하고있는 것이 있습니까? Rust 또는 C ++ 스마트 포인터 / RAII가 같은 것이라고 생각하지 않습니다.

이 (고려 된) 예제를 보자.

void* resource1;
void* resource2;

while(true){

    int input = getInputFromUser();

    switch(input){
        case 1: resource1 = malloc(500); break;
        case 2: resource2 = resource1; break;
        case 3: useResource(resource1); useResource(resource2); break;
    }
}

언제 무료로 전화해야합니까? malloc에 ​​할당하기 전에에 resource1복사 할 수 없기 때문에 할 수 없으며 resource2, 할당하기 전에 resource2개입하지 않고 사용자로부터 2를 두 번 받았기 때문에 할 수 없습니다.

유일하게 확인하는 유일한 방법은 resource1과 resource2를 테스트하여 1과 2의 경우 같지 않은지 확인하고 그렇지 않은 경우 이전 값을 해제하는 것입니다. 이것은 단지 2 개의 가능한 참조 만이 있다는 것을 알고있는 참조 카운트입니다.

RAII는 자동으로 동일한 것은 아니지만 효과는 동일합니다. "더 이상 액세스 할 수없는 시점을 어떻게 알 수 있습니까?"라는 질문에 쉽게 대답 할 수 있습니다. 특정 자원이 사용될 때 영역을 커버하기 위해 범위 를 사용하여 .

비슷한 문제 "런타임에 프로그램 오류가 발생하지 않는지 어떻게 알 수 있습니까?" 이에 대한 해결책은 없는 등의 오류가있을 수 없음을 증명하는 프로그램을 통해하지만 형의 주석과 추론의 시스템을 사용하여 모든 실행 경로를 예측. 녹은이 증명 속성을 메모리 할당으로 확장하려는 시도입니다.

정지 문제를 해결하지 않고 프로그램 동작에 대한 증거를 작성할 수 있지만, 어떤 종류의 주석을 사용하여 프로그램을 제한하는 경우에만 가능합니다. 보안 증명 (sel4 등)도 참조하십시오.

예, 이것은 야생에 존재합니다. ML Kit 는 사용 가능한 메모리 관리 옵션 중 하나로 전략을 설명하는 프로덕션 품질의 컴파일러입니다. 또한 기존 GC를 사용하거나 참조 카운팅과 혼성화 할 수 있습니다 (힙 프로파일 러를 사용하여 실제로 어떤 전략이 프로그램에 가장 적합한 결과를 산출하는지 확인할 수 있습니다).

리전 기반 메모리 관리에 대한 회고 는 ML Kit의 최초 작성자가 성공 및 실패를 기록한 기사입니다. 최종 결론은 힙 프로파일 러의 도움을 받아 작성할 때 전략이 실용적이라는 것입니다.

(이것은 실제 공학 질문에 대한 답변을 위해 일반적으로 Halting Problem을 보지 않아야하는 이유를 잘 보여줍니다. 우리는 가장 현실적인 프로그램의 일반적인 경우를 원치 않거나 해결할 필요 가 없습니다 .)

프로그램 제어 흐름의 모든 순열을 예측

이것이 문제가있는 곳입니다. 사소하지 않은 프로그램에 대해서는 순열의 양이 너무 커서 (실제로는 무한대), 필요한 시간과 메모리가이를 완전히 비실용적으로 만들 수 있습니다.

정지 문제는 이것이 모든 경우에 가능하지 않다는 것을 증명합니다. 그러나 여전히 많은 경우에 가능하며 실제로는 대부분의 변수에 대해 거의 모든 컴파일러가 수행합니다. 이것은 컴파일러가 장기 힙 스토리지 대신 스택 또는 레지스터에 변수를 할당하는 것이 안전하다는 것을 알려주는 방법입니다.

순수 함수 또는 소유권 의미론이 좋은 경우 정적 분석을 추가로 확장 할 수 있지만 코드에 더 많은 분기를 추가하는 것은 엄청나게 비용이 많이 듭니다.

단일 프로그래머 또는 팀이 전체 프로그램을 작성하는 경우 메모리 (및 기타 리소스)를 비워야하는 위치에서 설계 지점을 식별 할 수있는 것이 합리적입니다. 따라서보다 제한된 상황에서는 설계의 정적 분석이 충분할 수 있습니다.

그러나 타사 DLL, API, 프레임 워크를 고려하고 스레드를 처리하는 경우 사용 프로그래머가 어떤 엔티티가 어떤 메모리를 소유하고 있는지에 대해 올바르게 추론하는 것은 매우 어려울 수 있습니다 (모든 경우에 불가능합니다) 그것을 마지막으로 사용했을 때. 우리가 일반적으로 사용하는 언어는 객체와 배열의 메모리 소유권이 얕고 깊다는 것을 충분히 문서화하지 못했습니다. 프로그래머가 (정적으로 또는 동적으로) 그것을 추론 할 수 없다면 컴파일러는 그럴 수도 없습니다. 다시 말하지만, 메모리 소유권 전송은 메소드 호출이나 인터페이스 등에서 캡처되지 않기 때문에 코드에서 메모리를 해제 할 시점과 위치를 정적으로 예측할 수 없습니다.

이것은 심각한 문제이므로 많은 현대 언어는 가비지 수집을 선택합니다. 가비지 수집은 마지막 실시간 참조 후 언젠가 자동으로 메모리를 회수합니다. GC의 성능 비용은 특히 (실시간 응용 프로그램의 경우) 상당히 크지 만 보편적 인 치료법은 아닙니다. 또한 GC를 사용하여 메모리 누수가 계속 발생할 수 있습니다 (예 : 증가하는 컬렉션). 그러나 이것은 대부분의 프로그래밍 연습에 좋은 솔루션입니다.

몇 가지 대안이 있습니다 (일부 부상).

Rust 언어는 RAII를 극한으로 만듭니다. 클래스와 인터페이스의 메소드에서 소유권을 이전하는 방법, 예를 들어, 발신자와 수신자 사이에 또는 이전보다 긴 객체에서 차용되는 객체를 더 자세하게 정의하는 언어 구조를 제공합니다. 메모리 관리에 대해 높은 컴파일 시간 안전성을 제공합니다. 그러나 선택하는 것은 사소한 언어가 아니며 문제가없는 것도 아닙니다 (예를 들어 디자인이 완전히 안정적이라고 생각하지 않으며 특정 것들이 여전히 실험 중이므로 변경되고 있다고 생각합니다).

Swift와 Objective-C는 또 다른 경로를 사용합니다. 이는 대부분 자동 참조 횟수입니다. 참조 카운트는 사이클과 관련된 문제를 야기하며, 특히 폐쇄와 같은 심각한 프로그래머 문제가 있습니다.

프로그램이 알려지지 않은 입력에 의존하지 않는다면 가능해야합니다 (복잡한 작업 일 수 있고 시간이 오래 걸릴 수 있다는 경고가 있지만 프로그램에서도 마찬가지입니다). 이러한 프로그램은 컴파일 타임에 완전히 해결할 수 있습니다. C ++ 용어로, (거의) 완전히 constexprs 로 구성 될 수 있습니다 . 간단한 예는 pi의 처음 100 자리를 계산하거나 알려진 사전을 정렬하는 것입니다.

일반적으로 메모리를 비우는 것은 중지 문제와 같습니다. 프로그램이 (정적으로) 중지되는지 여부를 정적으로 알 수 없으면 메모리를 (정적으로) 비 울지 여부를 알 수 없습니다.

function foo(int a) {
    void *p = malloc(1);
    ... do something which may, or may not, halt ...
    free(p);
}

https://ko.wikipedia.org/wiki/Halting_problem

즉, Rust는 매우 훌륭합니다 ... https://doc.rust-lang.org/book/ownership.html