При реализации интерпретатора, хорошо или плохо совмещать сборщик мусора с языка хоста?

Question

Допустим, вы реализуете переводчик для языка GCed на языке GCed. Мне кажется, что вы будете получать сборщик мусора бесплатно, если вы достаточно осторожны в отношении своего дизайна.

Это вообще как это делается? Есть ли веские причины не делать этого?

Answer 1

Язык и время выполнения - две разные вещи. Они на самом деле не связаны ИМХО.

Поэтому, если ваша существующая среда выполнения уже предлагает GC, должна быть веская причина для расширения среды выполнения с другим GC. В старые добрые времена, когда распределение памяти в ОС было медленным и дорогостоящим, в приложениях были свои собственные диспетчеры кучи, которые были более эффективными при работе с небольшими порциями данных. Это было одно чтение для добавления другого управления памятью в существующую среду выполнения (или ОС). Но если вы говорите на Java, .NET или около того - они должны быть хорошими и достаточно эффективными для большинства задач.

Однако вы можете захотеть создать надлежащий интерфейс / API для задач управления памятью и объектами (и другими), чтобы ваша языковая («гостевая») среда выполнения могла быть позже реализована на другой среде выполнения хоста.

Answer 2

Для переводчика не должно быть проблем с использованием хоста GC, IMHO, особенно на первых порах.Как всегда, их цель должна состоять в том, чтобы заставить что-то работать, затем заставить это работать правильно, затем сделать это быстро.Это особенно верно для доменных языков (DSL), где целью является маленький язык.Для них реализация полного GC была бы излишней.