From ancient to a third Generation

From ancient to a third Generation

[Christophe Raffalli]

[-- Attachment #1.1: Type: text/plain, Size: 2078 bytes --]


The following idea traversed my mind reading the previous thread about 
ancient. May be I am missing something,
So I hope the expert could tell me if they think this is possible/good 
idea/bad idea

We could add to OCaml a third generation with the following properties:

- 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 ?)

- Objects in the third generation can be shared between processes (like 
in Ancient)

- 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 ...).

- 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.

- This third generation could be dealf with be a daemon and accessible 
by processes written using different languages ...

What do you think ?

 
-- 

Christophe Raffalli
Universite de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tel: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution 
can check this signature. The public key is
stored on www.keyserver.net
---------------------------------------------


[-- Attachment #1.2: Christophe_Raffalli.vcf --]
[-- Type: text/x-vcard, Size: 310 bytes --]

begin:vcard
fn:Christophe Raffalli
n:Raffalli;Christophe
org:LAMA (UMR 5127)
email;internet:christophe.raffalli@univ-savoie.fr
title;quoted-printable:Ma=C3=AEtre de conf=C3=A9rences
tel;work:+33 4 79 75 81 03
note:http://www.lama.univ-savoie.fr/~raffalli
x-mozilla-html:TRUE
version:2.1
end:vcard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Berke Durak]

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