From: John Skaller <skaller@maxtal.com.au>
To: STARYNKEVITCH Basile <Basile.Starynkevitch@cea.fr>
Cc: caml-list@inria.fr
Subject: Re: GC with finalisation?
Date: Sat, 28 Aug 1999 14:29:26 +1000 [thread overview]
Message-ID: <3.0.6.32.19990828142926.009629c0@mail.triode.net.au> (raw)
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
next prev parent reply other threads:[~1999-08-30 13:47 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
1999-08-27 7:13 ` STARYNKEVITCH Basile
1999-08-28 4:29 ` John Skaller [this message]
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.19990828142926.009629c0@mail.triode.net.au \
--to=skaller@maxtal.com.au \
--cc=Basile.Starynkevitch@cea.fr \
--cc=caml-list@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