Re: GC with finalisation?

From: John Skaller (skaller@maxtal.com.au)
Date: Sat Aug 28 1999 - 06:29:26 MET DST


Message-Id: <3.0.6.32.19990828142926.009629c0@mail.triode.net.au>
Date: Sat, 28 Aug 1999 14:29:26 +1000
To: STARYNKEVITCH Basile <Basile.Starynkevitch@cea.fr>
From: John Skaller <skaller@maxtal.com.au>
Subject: Re: GC with finalisation?
In-Reply-To: <14278.15024.193052.853437@gargle.gargle.HOWL>

At 09:13 27/08/99 +0200, STARYNKEVITCH Basile wrote:
>>>>>> "John" == John Skaller <skaller@maxtal.com.au> writes:
>
> John> I could use some advice on this. I'm implementing a Python
> John> interpreter/compiler in Ocaml. Python class instances
> John> support __del__ methods -- that is, destructors.
>
>3 choices are then proposed. I suggest a fourth one:
>
> 4) patch the existing ocaml 2.02 garbage collector to allow finalized
> objects containing (for example) a single Ocaml value:
>
>this is not very difficult;

        I had thought of that, but I didn't include it in my list
for two reasons:

        1) I do not have the experience to undertake this task
without losing confidence in the resulting system. I have that
confidence now because I know the existing collector was written
by experts and has been tested by many users.

        2) It will mean my clients cannot build my product,
without installing and compiling a patched version of Ocaml:
bytecode versions won't work either.

>you'll have to create a new tag, i.e. add
>
> #define Finalwithvalue_tag 249
>
>to mlvalues.h
>
> then grep for Final_tag in the source, and add the case for
> Finalwithvalue_tag (which should handle as value its second word
> after the header, the first being the finalizer).
>
>Notice that ocaml finalizer (including those alreday provided thru
>Final_tag) should *not* allocate any value in the Ocaml heap (in
>contrast with Java finalizers).

        I see. This could be a problem in the first instance,
since the __del__ methods of Python class instances can
execute arbitrary code, invoking my ocaml Python interpreter:
this will certainly cause heap allocations.

        [This does not rule out a solution using indirection]

>On the other hand, I consider that finalized objects supported by the
>language (such as provided by Java & Python) are a mistake.

        I have a strong tendancy to agree with you; but I have
a problem implementing a language which does support automatic
finalisation, which I myself have used heavily. So I need
some kind of solution anyhow.

        I have a tendancy _not_ to patch ocaml for just this reason:
however, I do wonder how other people handle finalisation issues;
including (but not limited to) releasing system resources.

>In my opinion, finalized objects should not have a user-provided finalizer,
>but should only deal with system resources (file descriptors, X11
>windows, coded only in C)

        That has the disadvantage that it only handles system resources
for which you have a suitable implementation. It makes sense to
create 'user defined' resources, and manage them in ocaml.

        It would seem that a module defining a 'generic' collector
with finalisation could help solve this and other related problems;
without compromising the ocaml memory collector.

        Such a collector would have to be 'layered ontop' of
a system, instead of leveraging the ocaml collector, but that
would probably be an advantage in many ways: collecting
non-memory resources may well require different semantics
than optimised memory collection.

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



This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:24 MET