인터프리터를 구현할 때 호스트 언어의 가비지 컬렉터를 피기 백하는 것이 좋습니까?

Question

GCed 언어에 대한 인터프리터를 GCed 언어로 구현한다고 가정 해 보겠습니다. 디자인에 대해 충분히주의를 기울이는 한 무료로 가비지 컬렉션을받을 수 있습니다.

일반적으로 어떻게 이루어 졌습니까? 이것을하지 않는 좋은 이유가 있습니까?

Answer 1

언어와 런타임은 서로 다른 두 가지입니다. 그들은 IMHO와 관련이 없습니다.

따라서 기존 런타임이 이미 GC를 제공하는 경우 다른 GC로 런타임을 확장해야하는 정당한 이유가 있어야합니다. 옛날에 OS의 메모리 할당이 느리고 비쌌다면, 응용 프로그램은 작은 덩어리의 데이터를 더 효율적으로 처리 할 수있는 자체 힙 관리자를 가져 왔습니다. 이는 기존 런타임 (또는 OS)에 또 다른 메모리 관리를 추가하기위한 하나의 읽기 작업이었습니다. 그러나 Java, .NET 등을 말하는 경우에는 대부분의 작업을 수행하기에 충분하고 효율적이어야합니다.

그러나 메모리 ("guest") 런타임을 나중에 다른 호스트 런타임에서 구현할 수 있도록 메모리 및 객체 관리 작업 (및 기타)을위한 적절한 인터페이스/API를 만들 수 있습니다.

Answer 2

통역사의 경우, 처음에는 특히 호스트 GC, IMHO 사용에 문제가 없어야합니다. 언제나 그렇듯이 목표는 올바르게 작동하도록 만든 다음 올바르게 작동하게 한 다음 빨리 작동시키는 것입니다. 목표가 작은 언어 인 도메인 특정 언어 (DSL)의 경우 특히 그렇습니다. 이를 위해 전체 GC를 구현하는 것은 지나치게 어려울 수 있습니다.