Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: John Skaller <skaller@maxtal.com.au>
To: Markus Mottl <mottl@miss.wu-wien.ac.at>
Cc: caml-list@inria.fr (OCAML)
Subject: Re: GC with finalisation?
Date: Fri, 27 Aug 1999 15:10:06 +1000	[thread overview]
Message-ID: <3.0.6.32.19990827151006.0099e930@mail.triode.net.au> (raw)
In-Reply-To: <199908262009.WAA29246@miss.wu-wien.ac.at>

At 22:09 26/08/99 +0100, Markus Mottl wrote:
>> I seem to have several choices. 
>> 	1) implement reference counting for finalisation

>The main problem with reference counting is speed. 

	I was hoping to avoid it ..

>It is possible to
>resolve circular references in linear time, but the constant overhead
>and the associated memory requirements are simply too large.

	I think this is less of a problem than actually
writing the collector, and then changing all my code
to use it.

>I would leave all the work to the OCaml-GC: use module "Weak" to register
>values (eg.: objects) to be finalized. Then check these arrays from
>time to time and call appropriate finalization functions for objects
>that have been reclaimed.

	That is an interesting idea -- but it won't work,
because the destructor must be called _before_ the object
is destroyed by the system. For example, one of my objects
maintains the table of contents for a document,
and when the object becomes unreachable, it is printed
to a file as HTML. Obviously, the object still has to exist
at this point, and retain all attributes.

	However, your idea of using weak arrays may
be useful after all, if I can create a 'symbol' for the
object, and put that into the weak array: the symbols
contains lists of symbols, representing objects the
object depends on. The collector will now collect
symbols, and by checking the weak array I can
execute destructors, and then release it
for collection (by removing it from a corresponding
'strong' array).

	The problem is: it will be slower than
reference counting, and not be entirely synchronous.
The advantage is it will finalise unreachable 
objects with circular references. Also,
reference counting can be added anyhow,
to make non-circular finalisation synchronous.

	Hmm. Comments?


-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia





  reply	other threads:[~1999-08-28 17:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-08-24  3:36 John Skaller
1999-08-26 21:09 ` Markus Mottl
1999-08-27  5:10   ` John Skaller [this message]
1999-08-27  7:13 ` STARYNKEVITCH Basile
1999-08-28  4:29   ` John Skaller
1999-08-28 21:49   ` Markus Mottl
     [not found] <3.0.6.32.19990830144523.00964e20@mail.triode.net.au>
1999-08-30 12:31 ` Markus Mottl

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=3.0.6.32.19990827151006.0099e930@mail.triode.net.au \
    --to=skaller@maxtal.com.au \
    --cc=caml-list@inria.fr \
    --cc=mottl@miss.wu-wien.ac.at \
    /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