Re: [Caml-list] From ancient to a third Generation

[Berke Durak <berke.durak@exalead.com>]

Christophe Raffalli wrote:

> What do you think ?

I understand that, after noticing that objects in the ancient heap are
manually allocated and deleted, you thought about making the ancient
heap garbage-collected.  So far so good.

 > - Objects are moved to this third generation either manually (or created
 > there) or automatically after surviving k major GC (k may be ajustable at
 > runtime ? k = 0 means never ?)

Moving them manually, or by a call to "share" seems more appropriate.
We don't want to unnecessarily clutter a permanent heap.

 > - There is a global greyval table, protected by a mutex, and an object
 > must be added in the table of greyval when mutated if it is a pointer
 > pointing to the major or minor heap of a specific process. Then, the object
 > stops to be accessible for reading by other processes (Here there is room to
 > change the design ...).

I don't understand this paragraph, could you reformulate?  What do you mean
by "stops being accessible"?  How is this checked?  Wouldn't that require
extra run-time checks?

 > - This third generation could be dealf with be a daemon

I like this idea.  It's a little bit like the Java server VM idea, except
that it just manages memory.

 > and accessible by processes written using different languages ...

Well, if by processes written using different language you mean languages
bound to C code using the Ocaml macros...

 > - Objects in the third generation are collected by a reference counter +
 > a specific GC: the counter counts the number of processes
 > holding at least one pointer to this object from their own stack, major
 > or minor heap. This counter is only increased/decreased by the GC of
 > each process
 > (a mutex is neeeded here). There is also a specific GC process (mark and
 > sweep ?). To take care of pointers from the third generation to the
 > third generation
 > and make sure that object with a zero counter can be removed.

I see a few problems:

a) The daemon will need to ask all the accessing processes to mark their
ancient values before collecting.

b) What about cycles traversing multiple heaps?  Maybe that's what your
obscure paragraph was talking about.

c) What representation will the values in the third generation use?  If
you need extra GC information (such as a refcounter), you will add significant
overhead to values: you will need at least an extra word per block header.
-- 
Berke DURAK