From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: Mark procedures Date: Thu, 05 Nov 2015 15:17:36 +0100 Message-ID: <87pozo5y4f.fsf@gnu.org> References: <87vb9ihy6x.fsf@igalia.com> <87bnb891t8.fsf@gnu.org> <87ziyspp5d.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1446733083 28463 80.91.229.3 (5 Nov 2015 14:18:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Nov 2015 14:18:03 +0000 (UTC) Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Nov 05 15:17:56 2015 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZuLMR-0007Ea-N4 for guile-devel@m.gmane.org; Thu, 05 Nov 2015 15:17:55 +0100 Original-Received: from localhost ([::1]:60906 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuLMR-0006NL-8a for guile-devel@m.gmane.org; Thu, 05 Nov 2015 09:17:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuLMG-0006Mx-3J for guile-devel@gnu.org; Thu, 05 Nov 2015 09:17:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuLMB-0005KG-71 for guile-devel@gnu.org; Thu, 05 Nov 2015 09:17:43 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuLMB-0005KB-43; Thu, 05 Nov 2015 09:17:39 -0500 Original-Received: from pluto.bordeaux.inria.fr ([193.50.110.57]:56252 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZuLMA-00034Z-Ax; Thu, 05 Nov 2015 09:17:38 -0500 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 15 Brumaire an 224 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x3D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87ziyspp5d.fsf@pobox.com> (Andy Wingo's message of "Thu, 05 Nov 2015 14:11:10 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17983 Archived-At: Andy Wingo skribis: > Some of the points I made have not been made before, AFAIK. The point > about marking occuring concurrently with the mutator even in the absence > of threads, for example. Yes, right. >> I agree with you that we must keep recommending against using [mark >> procedures], and that remaining uses should probably be questioned; I >> think we can=E2=80=99t =E2=80=9Cjust=E2=80=9D remove them though. > > I am not sure, to be honest. I am not proposing "just" removing them. > However if we can remove them, then we *certainly* should do so -- we > should plan our API in that way. Right. I think we cannot remove them yet, but we should do what it takes so users rely less and less on them. >> What we need above all is to address LilyPond=E2=80=99s use case. I pro= posed a >> solution at but >> never understood whether/why it was considered unfit. > > I agree with you that the patch there looks reasonable to me too, though > AFAIU the original code should work just fine too. > > There area few things at play. > > (1) A bug related to SMOB finalization and marking that affects > LilyPond > > (2) The utility of mark procedures in general > > (3) The suitability of mark procedures for future uses > > (4) Whether we can get by without mark procedures, and if so, how. > > For (1) it seems to me that we just have a bug. A SMOB mark function > was called on an object after the finalizer. ****Note**** that having > the finalizer called doesn't mean that the GC object was collected -- it > just means it was collectable, perhaps in a clique of objects. > Finalization being asynchronous with marking it's possible that a clique > of objects was only half-finalized when a new mark procedure runs. The > mark procedure saw an object on which free() was already called -- this > is possible. > > We should fix Guile so to "null out" the SMOB typecode when the SMOB > finalizer is called. If our mark procedure sees a SMOB that has already > been finalized, it just returns. > > Though finalizers in general can resuscitate objects, that was never a > contract of SMOB finalizers, and I think in fact it's an anti-contract. > Unfortunately for maximum robustness we probably need to grab the alloc > lock when swapping out the typecode; too bad. This is not the same as > marking dead objects on free lists. An object is first finalized, then > BDW-GC removes its finalizer, then if it is collected in the next GC it > goes on a freelist. Since (1) is difficult to fix, and since mark procedures have other problems as you explain, I was inclined to address the Lily problem via (4). > For (2). To me the existence of other systems with proper GC but no > mark procedures, especially JS VMs, means that mark procedures are not > _necessary_. Point taken. BDW-GC makes them useless in most cases anyway. > For (3) I hope I have successfully argued that what we need for precise > and moving collection is not the same as mark procedures. I think Mark > would like to deal with these topics at the same time but I strongly > disagree. I think so. I admit I=E2=80=99m more concerned with the immediate problems= of LilyPond though. ;-) > Point (4) indicates to me that if we are making new abstractions that we > would like to encourage people to use in the future, we should not > encourage mark functions. We can add some other mechanism (type > descriptors, for example). SMOBs and their horrible mark procedures > aren't going away any time soon, of course. Agreed! Commit d9a4a1c uses very clear wording to recommend against mark procedures, which is the right thing IMO; commit 56273de from 2009 already hinted in that direction, though not as prominently. Since I missed the original discussion between you and Mark, I might well be completely off, in which case I apologize. Thanks, Ludo=E2=80=99.