Any thoughts about adding precise garbage collection to Neko?
Or does the code implicitly assume [conservative] GC throughout its design?
Neko is currently using the (consersavative) Boehm GC
(its author compare the approach with a precise gc
http://www.hpl.hp.com/personal/Hans_Boehm/gc/conservative.html)
The only problem I see with precise GC is that it requires a lot more
macro work when writing C primitives and you can easily introduce GC
bugs if you forget to register one of your stack values. OCaml is a good
example of this, and I wanted to keep Neko C API as much easy as possible.
In your experience, is Boehm GC reliable for large optimized programs
or very long lived processes?
Yes, it is.
I was unable to find the cause of the gcc 4.1.1 -O[123] build crash in
part due to memory explosion. The neko process was using over 2G of swap
space on my 512M machine. I wonder if this was due to a failure of
Boehm GC due to a bad interaction with a certain compiler optimization
in this specific version of gcc.
I think that's due to an infinite loop that's causing too much memory
allocation. It doesn't happen because of the GC since it can't be
reproduced by just recompiling Neko with other GCC/-O flags.
Nicolas
--
Neko : One VM to run them all
(http://nekovm.org)
