From: Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>
To: Caml Mailing List <caml-list@yquem.inria.fr>
Subject: From ancient to a third Generation
Date: Mon, 12 May 2008 20:19:45 +0200 [thread overview]
Message-ID: <48288A41.4030501@univ-savoie.fr> (raw)
[-- 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 --]
next reply other threads:[~2008-05-12 18:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-12 18:19 Christophe Raffalli [this message]
2008-05-13 9:18 ` [Caml-list] " Berke Durak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48288A41.4030501@univ-savoie.fr \
--to=christophe.raffalli@univ-savoie.fr \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox