From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Marking weak alist vectors Date: Wed, 14 Dec 2005 10:30:14 +0100 Organization: LAAS-CNRS Message-ID: <874q5cyqjd.fsf@laas.fr> References: <87y83z3vh5.fsf@laas.fr> <874q6m7l6d.fsf@zagadka.de> <87lkzyyyzw.fsf@laas.fr> <87vey13hn2.fsf@zagadka.de> <8764q1tcvu.fsf@laas.fr> <87pso0tvbd.fsf@zagadka.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1134574194 30337 80.91.229.2 (14 Dec 2005 15:29:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 14 Dec 2005 15:29:54 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Dec 14 16:29:44 2005 Return-path: Original-Received: from [199.232.75.2] (helo=lists.gnu.org) by ciao.gmane.org with esmtp (Exim 4.43) id 1EmYUU-0007zK-PY for guile-devel@m.gmane.org; Wed, 14 Dec 2005 16:24:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EmYJh-00041g-UI for guile-devel@m.gmane.org; Wed, 14 Dec 2005 10:13:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EmTYz-0007wh-HX for guile-devel@gnu.org; Wed, 14 Dec 2005 05:08:46 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EmTT9-0007Nx-Qo for guile-devel@gnu.org; Wed, 14 Dec 2005 05:02:47 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EmTGs-0005qY-F8 for guile-devel@gnu.org; Wed, 14 Dec 2005 04:50:06 -0500 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EmTIv-00006h-3D for guile-devel@gnu.org; Wed, 14 Dec 2005 04:52:09 -0500 Original-Received: by laas.laas.fr (8.13.1/8.13.4) with SMTP id jBE9UXfW018763; Wed, 14 Dec 2005 10:30:35 +0100 (CET) Original-Received: from messiaen.laas.fr (messiaen [140.93.21.6]) by laas.laas.fr (8.13.1/8.13.4) with SMTP id jBE9UXfW018763; Wed, 14 Dec 2005 10:30:34 +0100 (CET) Original-Received: by messiaen.laas.fr (sSMTP sendmail emulation); Wed, 14 Dec 2005 10:30:14 +0100 Original-To: Marius Vollmer X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 24 Frimaire an 214 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Marius Vollmer , guile-devel@gnu.org In-Reply-To: <87pso0tvbd.fsf@zagadka.de> (Marius Vollmer's message of "Wed, 14 Dec 2005 01:45:58 +0200") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org X-Broken-Reverse-DNS: no host name found for IP address 199.232.75.2 Xref: news.gmane.org gmane.lisp.guile.devel:5512 Archived-At: Hi Marius, Marius Vollmer writes: > Yes, SMOBs could profit from a guarantee about the order of > finalization, but I don't think that guarantee can be implemented > cheaply enough. (Or can it?) > > So, my current point of view is that smobs have to suffer in order to > make live easier for the GC. IMO, it's not just a fancy improvement for SMOBs but a requirement. That is, if we cannot provide this guarantee, then we have to either completely remove SMOBs (hmm, not sure this is a good idea ;-)) or disallow their use in weak vectors. Again, for the SMOB programmer viewpoint, the order of "finalization" is something that should be taken seriously. >> SMOBs shouldn't ever have the impression that a value attached to a weak >> key is freed _before_ that weak key. > > This would not only apply to weak keys etc, but to all kinds of > references, right? I.e., all SCM values belonging to a smob would be > guaranteed to be valid when the free function for that smob is called. > Thus, we are not only talking about your patch for weak hash tables, > but about big changes to the GC in general, right? Well, maybe you're extrapolating too much. ;-) Of course, this issue is very similar to the one I raised initially. However, a SMOB that embeds SCM values knows that it is responsible for marking them. Therefore, when a SMOB is freed (because it hasn't been marked), it knows that the SCM values under its control may have remained unmarked as well and may have been GC'd. So I think the semantics here are different: you cannot reasonably expect SCM values embedded within a SMOB to be freed after the SMOB. > Heh, that is not an example, that is a test case. :-) Yeah, but it's pretty close to an example. ;-) >> For a more general example where this is an issue: >> http://lists.nongnu.org/archive/html/g-wrap-dev/2005-09/msg00006.html >> (see at the bottom). > > (I only read the article you linked to directly, not the thread.) > > So you have a C API that requires a certain order for freeing objects > and that order needs to be honored by the smobs that wrap the objects, > right? Right. > My immediate reaction is to suggest to fix this by layering something > on top of the C API, such as the reference counting that you mention > in your article. (Refcounting is acceptable since cycles must be > prevented anyway.) Sure, reference counting is the usual way to solve that problem (for instance, that's how glib, gnet, etc. solve this). But I was convinced that using object properties would achieve the same goal much more easily. > But note that the thing we are talking about now is very different > from what you started out with: now we are not talking about in which > run of the GC a value belonging to a weak key is collected (i.e., the > key in run n, the value in run n+1), but in what order objects are > finalized within a single run of the GC (if I am not confused now). As stated earlier, I think your attempt to generalize the problem is unfruitful. ;-) I.e., IMO, the general issue of the order of finalization within a single run of the GC isn't an actual issue. We can really tackle the first problem (i.e., "in which run a value belonging to the GC is collected") without having to worry about the order of finalization in general. Furthermore, I think the patch shows that the first issue can be fixed without introducing a significant performance cost. The second version of the patch introduces _some_ overhead in `scm_i_remove_weaks ()', because it needs to iterate on MARK_QUEUE, but that doesn't seem to be too much of a burden. In [0], this issue is not even mentioned. In fact, I believe it is quite specific to Guile since other Scheme implementations maybe don't have such a large C API. Further research suggests that this is also an issue in languages such as SmallTalk where finalization is visible to the application [1,2]. The Java specs (almost) clearly state that a weak reference is only finalized after the object it refers to has become "weakly reachable" (well, in the end it says nothing about the finalization of the object itself...) [3]. Thanks, Ludovic. [0] http://www.haible.de/bruno/papers/cs/weak/WeakDatastructures-writeup.html [1] http://mail.python.org/pipermail/python-dev/2003-November/040299.html [2] http://www.mimuw.edu.pl/~sl/teaching/00_01/Delfin_EC/Overviews/WeakReferencesAndFinalization.htm [3] http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ref/WeakReference.html _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel