가비지 수집기가 힙의 객체를 압축하면 스택의 참조가 변경됩니까?

이것은 간단한 질문처럼 보이지만 주제를 많이 읽은 후에도 여전히 명확한 대답을 찾지 못했습니다 (아마도 너무 간단하기 때문에).

내 질문은 이것입니다 : 가비지 수집기가 힙의 객체를 압축하면 스택의 해당 객체에 대한 참조가 어떻게 업데이트됩니까? 두 가지 가능한 솔루션을 생각할 수 있습니다.

스택 (및 힙의 참조)을 살펴보고 객체의 새 위치를 가리 키도록 참조를 업데이트하십시오. 이사와 비슷하게, 이것은 주소를 가진 사람에게 편지를 보내고 새 주소로 주소록을 업데이트하도록 요청하는 것과 같습니다.
일종의 룩업 테이블을 제공하십시오. 이것은 지역 우체국에 전달 주소를 남기는 것과 같습니다.

가비지 수집기는이 두 가지 방법 중 하나를 주로 사용합니까? 다른 방법? 양자 모두?

garbage-collection

— 토 도로로
소스

stackoverflow.com/questions/3799203/… 및 en.wikipedia.org/wiki/…를

— 로봇 고트

@StevenBurnap은 내가 틀렸다면 나를 수정하지만, 연결된 스레드에 명확한 대답이 없다고 생각합니다. 그들은이 정확한 질문에 대해서도 추측하는 것처럼 보였습니다. 잘못 읽었을 수 있습니다. 그들이 질문에 대한 답변을 제공했다면, 마음에 들지 않는다면, 미래의 SE 사용자 (그리고 나 자신을 위해)에 대한 답변을 여기에 요약하는 것이 도움이 될 것이라고 생각합니다.

— todorojo

당신이 말하는 것에 대한 용어는 "움직이는 가비지 수집기"입니다. 나는 그들이 얼마나 일반적으로 사용되는지 모르겠다.

— 로봇 고트

이에 대한 특정 전문 지식은 없지만 첫 번째 방법이 일반적으로 사용된다는 것을 이해하고 있습니다.

가비지 수집기는 스택에서 힙의 항목을 참조하기 위해 스택을 분석해야합니다. 일단 무언가를 옮기기로 결정하면 어쨌든 그것에 대한 참조를 수정해야하며, 그 시점에서 힙과 스택을 구별 할 이유가 없습니다.

룩업 테이블 접근법은 원칙적으로 작동 할 수 있습니다. 그러나 모든 포인터 액세스에는 2 단계가 필요합니다. 이는 정상적인 런타임에 큰 영향을 미칩니다. 특히 많은 작은 물체의 사용 사례에 적합합니다. (최신 GC 프로그램의 상태가 일반적으로 참조 횟수를 초과하는 경우입니다.)

— btilly
소스

나는 GC가 필요하지 않은 한 힙에서 물건을 옮기지 않을 것이라고 생각한다고 덧붙였다 . 오늘날의 다중 프로세서 환경에서 이러한 참조를 사용하는 프로그램이 실행되는 동안 힙에있는 모든 참조를 업데이트해야하는 경우 동기화 악몽이되어야합니다. 조회 테이블은 이것을 단순화하지만 표준이 아닌 예외라고 생각하므로 대부분의 GC는 아마도 일부 참조를 잠그고 메모리를 이동 한 다음 참조를 업데이트해야합니다. +1 재미있는 질문, +1 좋은 답변.

— GlenPeterson

@GlenPeterson 많은 GC는 실제로 힙 위에서 물건을 옮기지 않으며이 문제에 직면하지 않습니다. 그러나 정의에 따라 압축 GC는 라이브 객체를 메모리 조각 모음으로 이동시킵니다.

— btilly

@GlenPeterson 힙에 물건을 옮기는 것은 큰 동기화 고통이라는 것이 잘 관찰됩니다 .GC 압축은이로 인해 실행중인 프로세스에 큰 파급 효과가 있지만 간과되지는 않습니다. 사람들이 압축을 길게하여 긴 뮤텍스를 유지하도록하는 힙 힙 업데이트를 피하기 위해 가능한 한 짧은 기간 동안 객체를 유지하기 위해 가능한 모든 작업을 수행해야한다는 것이 가장 큰 이유입니다. 이 물건이 행동하는 방식에 대한 무지가 사랑스럽게 GC Freakout Mode라고 불리는 것으로 이어질 수 있습니다.

— Jimmy Hoffa

원래 Macintosh와 Palm OS는 모두 메모리 관리를 위해 조회 테이블 방식을 사용했습니다. 테이블에 대한 포인터를 핸들이라고했습니다. 재배치하는 GC는 움직이고있는 물체에 대한 절대적으로 모든 참조의 위치를 알아야합니다. 이러한 목적으로 단일 테이블을 사용하면 작업이 크게 단순화됩니다.

— 슈퍼 캣