Re: precise gc?

--- Nicolas Cannasse <ncannassemotion-twin.com> 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/conse
rvative.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&c
s=bz 

-- 
Neko : One VM to run them all
(http://nekovm.org)

>>> 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/conse
rvative.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)

On Sat, 2007-08-11 at 14:50 -0700, Joe Wilson wrote:

> In your experience, is Boehm GC reliable for large
optimized programs 
> or very long lived processes?

Boehm GC is reliable and robust *provided* you hook it up
properly.
It needs the right linker support, and the right compiler
and
application support, or it won't work. Things like C++
exceptions,
threads, link misordering, etc etc can create problems. From
that
viewpoint an application like Neko is very well supported
because
the interpreter and linkage and threading technologies are
finite
and well known.

Note that Boehm also allows 'precise' specifications: you
can
provide a bitmap with objects to locate pointers.

OTOH Felix uses a precise collector. User "C" code
heap objects
are simply not managed. If the user makes an STL Vector of
Felix
heap pointers, they're likely to dangle. OTOH the collector
has
to be called manually.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

-- 
Neko : One VM to run them all
(http://nekovm.org)