--- Nicolas Cannasse <[EMAIL PROTECTED]> wrote:
> Joe Wilson a écrit :
> > 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?
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.
____________________________________________________________________________________
Got a little couch potato?
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
--
Neko : One VM to run them all
(http://nekovm.org)
