From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: Mark procedures Date: Thu, 05 Nov 2015 14:11:10 +0100 Message-ID: <87ziyspp5d.fsf@pobox.com> References: <87vb9ihy6x.fsf@igalia.com> <87bnb891t8.fsf@gnu.org> 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 1446729101 25133 80.91.229.3 (5 Nov 2015 13:11:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Nov 2015 13:11:41 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Nov 05 14:11:32 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 1ZuKK9-0004Sh-LI for guile-devel@m.gmane.org; Thu, 05 Nov 2015 14:11:29 +0100 Original-Received: from localhost ([::1]:60577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuKK9-0008Q3-3u for guile-devel@m.gmane.org; Thu, 05 Nov 2015 08:11:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60519) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuKK3-0008Pw-UD for guile-devel@gnu.org; Thu, 05 Nov 2015 08:11:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuKJx-0001wz-Le for guile-devel@gnu.org; Thu, 05 Nov 2015 08:11:23 -0500 Original-Received: from pb-sasl0.int.icgroup.com ([208.72.237.25]:61720 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuKJx-0001vH-ER; Thu, 05 Nov 2015 08:11:17 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl0.pobox.com (Postfix) with ESMTP id 1B2C91E3C4; Thu, 5 Nov 2015 08:11:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=XRtNndODwh1g 7aUpopp8Fjy+qyo=; b=RhJYDMJfUUO8TU5uxTM6Zh4GDvV8/wD1KXvQYKwVwZqA ZDm+OPrg5qtQJjnsUoM5GIB6PfaZYPCRjXeWVo/sE1wx6JZ2mON/Lhc2jGZCRrL0 003mDM9bnsx5zcHLMd3/5VE3uxlcsrRPvBW+dtdMfYg1aiaZa540WAFrfzHIbvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=v8GpaG gk9sazucjd11Vlv60vPCPtbwto0Ef5YH7mLlDZwWH0aE+rP1UA25iytIalE3z6sh uRnvGARr48LhVWAFgD/INjeb8KTKSiWHS5XlRZq+8YrzSj5ek3QBd+KWVPB1GW4C LwOYRMQr81a0Ghr/aZetOrL2Z7dcsNdiUGpGo= Original-Received: from pb-sasl0.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl0.pobox.com (Postfix) with ESMTP id 136A71E3C3; Thu, 5 Nov 2015 08:11:15 -0500 (EST) Original-Received: from badger (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl0.pobox.com (Postfix) with ESMTPSA id 5201E1E3C2; Thu, 5 Nov 2015 08:11:14 -0500 (EST) In-Reply-To: <87bnb891t8.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Thu, 05 Nov 2015 11:29:39 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) X-Pobox-Relay-ID: B132D5CC-83BE-11E5-BC78-31311E2D4245-02397024!pb-sasl0.pobox.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.72.237.25 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:17982 Archived-At: On Thu 05 Nov 2015 11:29, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > I think we all agree that mark procedures suck in many ways, so that=E2= =80=99s > not the problem. :) 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. > 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. > What we need above all is to address LilyPond=E2=80=99s use case. I prop= osed 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. 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_. 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. 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. Andy --=20 http://wingolog.org/