Ao implementar um intérprete, é bom ou ruim pegando o coletor de lixo do idioma host?

Question

Digamos que você esteja implementando um intérprete para um idioma GCED em um idioma que é GCED. Parece -me que você receberá a coleção de lixo de graça, desde que seja razoavelmente cuidadoso com o seu design.

É geralmente assim que é feito? Existem boas razões para não fazer isso?

Answer 1

Linguagem e tempo de execução são duas coisas diferentes. Eles não estão realmente relacionados IMHO.

Portanto, se o seu tempo de execução existente já oferece um GC, deve haver um bom motivo para estender o tempo de execução com outro GC. Nos bons velhos tempos, quando as alocações de memória no sistema operacional eram lentas e caras, os aplicativos trouxeram seus próprios gerentes de heap, que eram mais eficientes para lidar com pequenos pedaços de dados. Esse foi um Readon para adicionar outro gerenciamento de memória a um tempo de execução existente (ou SO). Mas se você está falando de Java, .Net ou mais - eles devem ser bons e eficientes o suficiente para a maioria das tarefas em mãos.

No entanto, convém criar uma interface/API adequada para tarefas de gerenciamento de memória e de objetos (e outros), para que seu idioma ("convidado") o tempo de execução possa ser implementado em outro tempo de execução do host posteriormente.

Answer 2

Para um intérprete, não deve haver problema em usar o host GC, IMHO, principalmente no início. Como sempre, eles devem ser fazer algo funcionando e, em seguida, fazê -lo funcionar certo e, em seguida, faça -o rápido. Isso é particularmente verdadeiro para idiomas específicos de domínio (DSL), onde o objetivo é um idioma pequeno. Para isso, a implementação de um GC completo seria um exagero.