Me gustaría utilizar una máquina virtual como NekoVM en un dispositivo pequeño pero para construirlo, requiere Boehm GC, sin embargo, no hay puerto de ese GC para ese pequeño dispositivo, así que me preguntaba si hay alguna alternativa para ello. , algo que podría hacerse exclusivamente con el código C?¿Qué alternativas a Hans Boehm GC existen para dispositivos pequeños?
Diría que su mejor opción sería llevar el GC a su plataforma, para lo cual hay instrucciones (libgc porting instructions).
Además, debería ser posible cambiar la implementación del GC (NekoVM FAQ), ver el archivo vm/alloc.c.
EDITAR:
suerte útiles enlaces adicionales: (no probado)
Quizás sea mejor que usted con Lua, que tiene una máquina virtual muy pequeña pero poderosa, tiene su propio recolector de basura integrado y se ejecuta en cualquier plataforma que admita ANSI estándar C. Con solo un poco de esfuerzo puede incluso construya Lua en una máquina que carece de entrada estándar y salida estándar. He visto a Lua corriendo en un dispositivo incrustado que era small LCD touch screen with an embedded CPU stuck on the back. Neko es un buen trabajo, pero creo que encontrarás a Lua igual de satisfactoria.
Soy consciente de que Lua tiene su propio recolector de basura, pero si miras NekoVM usan libgc y no usan un GC como Lua porque no es tan bueno como libgc. Estoy buscando un CG de uso general como libgc que podría reemplazar en nekoVM –
Hans ha pasado literalmente más de 20 años mejorando libgc. No es realista esperar encontrar un reemplazo directo para un colector de alto rendimiento. Tampoco es sensato esperar GC de alto rendimiento en un dispositivo pequeño. Su pregunta fue para 'una máquina virtual como NekoVM'. Lua califica. –
Hans puede haber pasado más de 20 años mejorando libgc pero su rendimiento es horrible en comparación con los recolectores de basura más precisos. –
Para admitir esto, hay una presentación de VMKit (LLVM) donde muestran Boehm GC como probable bottleneck para el rendimiento.
Sí, realmente comenzaría a usar VMKit si solo tuvieran un GC mejor. El Boehm GC es demasiado lento cuando ejecuta un lenguaje seguro. – Zifre
@Zifre: FWIW, escribir un GC preciso es realmente fácil. La implementación que hice en HLVM es solo alrededor de 100 líneas de código ... –
Podría sugerir TinyGC (tinygc.sf.net) - una implementación liviana e independiente de BoehmGC dirigida a dispositivos pequeños. Es totalmente compatible con API (incluso más, compatible con binarios) con BoehmGC v7 + pero solo se implementa un pequeño subconjunto de la API (pero suficiente para la gestión de memoria similar a Java/GCJ) y no hay subprocesos automáticos y registro de raíces de datos estáticos. Sin embargo, esto último puede requerir algunos esfuerzos para hacer que NekoVM trabaje con él (es decir, llame a GC_register_my_thread() y GC_add_roots()).
Mi consejo es escribir un GC preciso para Neko si aún no existe uno. No tocaría el GC de Boehm con un poste de barcaza ...
Puede agregar mi [Qish GC] (http://starynkevitch.net/Basile/qishintro.html) incluso si ya no trabajo en él ... –
@downvoter: Is hay algo mal con esta respuesta? Un comentario ayudaría a mejorarlo. – Hasturkun