[Neko] precise gc?
ncannasse at motion-twin.com
Sun Aug 12 00:53:01 CEST 2007
>>> 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
>> 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 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.
More information about the Neko