From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA22828 for caml-redistribution; Mon, 30 Aug 1999 15:47:40 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id IAA28104 for ; Sat, 28 Aug 1999 08:52:27 +0200 (MET DST) Received: from iggy.triode.net.au (iggy.triode.net.au [203.63.235.1]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id IAA07912 for ; Sat, 28 Aug 1999 08:52:22 +0200 (MET DST) Received: from egret (pm1-7.triode.net.au [203.63.235.23]) by iggy.triode.net.au (8.9.3/8.8.8) with SMTP id QAA28157; Sat, 28 Aug 1999 16:49:20 +1000 Message-Id: <3.0.6.32.19990828142926.009629c0@mail.triode.net.au> X-Sender: skaller@mail.triode.net.au X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Sat, 28 Aug 1999 14:29:26 +1000 To: STARYNKEVITCH Basile From: John Skaller Subject: Re: GC with finalisation? Cc: caml-list@inria.fr In-Reply-To: <14278.15024.193052.853437@gargle.gargle.HOWL> References: <3.0.6.32.19990824133643.009a89a0@mail.triode.net.au> <3.0.6.32.19990824133643.009a89a0@mail.triode.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: weis At 09:13 27/08/99 +0200, STARYNKEVITCH Basile wrote: >>>>>> "John" == John Skaller 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