[haskell] Haskell에 가비지 수집기가 필요합니까?

다른 사람들이 이미 지적했듯이 Haskell은 자동 , 동적 메모리 관리 : 수동 메모리 관리가 안전하지 않기 때문에 자동 메모리 관리가 필요하다 일부 프로그램의 경우 개체의 수명이 런타임에만 결정될 수 있기 때문에 동적 메모리 관리가 필요합니다.

예를 들어, 다음 프로그램을 고려하십시오.

main = loop (Just [1..1000]) where
  loop :: Maybe [Int] -> IO ()
  loop obj = do
    print obj
    resp <- getLine
    if resp == "clear"
     then loop Nothing
     else loop obj

이 프로그램에서 목록 [1..1000]은 사용자가 “clear”를 입력 할 때까지 메모리에 보관되어야합니다. 따라서 이것의 수명은 동적으로 결정 되어야 하며, 이것이 동적 메모리 관리가 필요한 이유입니다.

그래서 이런 의미에서, 자동화 된 동적 메모리 할당이 필요하며, 실제로이 방법은 : 예 가비지 컬렉션은 최고 성능의 자동 동적 메모리 관리자이기 때문에, 하스켈은 가비지 컬렉터가 필요합니다.

하나…

가비지 수집기가 필요하지만 컴파일러가 가비지 수집보다 저렴한 메모리 관리 체계를 사용할 수있는 특수한 경우를 찾으려고 할 수 있습니다. 예를 들어, 주어진

f :: Integer -> Integer
f x = let x2 = x*x in x2*x2

컴파일러가 반환 x2시 안전하게 할당 해제 될 수 있음 을 감지하기를 바랍니다 f(가비지 수집기의 할당 해제를 기다리는 대신 x2). 본질적으로 컴파일러는 가능한 경우 할당을 가비지 수집 된 힙으로 변환 하여 스택의 할당으로 변환 하도록 이스케이프 분석 을 수행하도록 요청 합니다.

이것은 요청하기에 너무 불합리 하지 않습니다. GHC는 그렇지 않지만 jhc haskell 컴파일러 가이를 수행합니다. Simon Marlow 는 GHC의 세대 별 가비지 수집기가 탈출 분석을 거의 불필요하게 만든다고 말합니다 .

jhc는 실제로 영역 추론으로 알려진 정교한 형태의 탈출 분석을 사용합니다 . 치다

f :: Integer -> (Integer, Integer)
f x = let x2 = x * x in (x2, x2+1)

g :: Integer -> Integer
g x = case f x of (y, z) -> y + z

이 경우 단순한 이스케이프 분석에서는 x2이스케이프 f가 튜플에서 반환되기 때문에 이스케이프가 발생하므로 x2가비지 수집 된 힙에 할당되어야 한다고 결론을 내립니다 . 반면에 지역 추론은 반환 x2시 할당 해제 될 수있는 것을 감지 할 수 있습니다 g. 여기서 아이디어는 의 지역이 아닌의 지역에 x2할당되어야한다는 것 입니다.gf

하스켈을 넘어서

지역 추론은 위에서 논의한 특정 경우에 도움이되지만 지연 평가와 효과적으로 조화를 이루는 것은 어렵습니다 ( Edward Kmett 및 Simon Peyton Jones의 의견 참조). 예를 들어

f :: Integer -> Integer
f n = product [1..n]

[1..n]스택에 목록을 할당하고 f반환 후에 할당을 해제하려는 유혹 이있을 수 있지만 이것은 치명적일 것입니다. fO (1) 메모리 (가비지 수집 아래)를 사용하는 것에서 O (n) 메모리로 변경됩니다.

엄격한 기능적 언어 ML에 대한 지역 추론에 대한 광범위한 작업이 1990 년대와 2000 년대 초에 수행되었습니다 . Mads Tofte, Lars Birkedal, Martin Elsman, Niels Hallenberg는 지역 추론에 대한 작업에 대해 꽤 읽기 쉬운 회고전 을 작성했으며 , 대부분은 MLKit 컴파일러에 통합되었습니다 . 그들은 순수 지역 기반 메모리 관리 (예 : 가비지 수집기 없음)와 하이브리드 영역 기반 / 가비지 수집 메모리 관리를 실험했으며 테스트 프로그램이 순수 가비지보다 “10 배 더 빠르게 4 배 더 느리게”실행되었다고보고했습니다. 수집 된 버전.

답변

f (x, y)