From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Mark procedures and LilyPond Date: Fri, 06 Nov 2015 07:32:51 -0500 Message-ID: <87io5ftij0.fsf_-_@netris.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 1446813213 20900 80.91.229.3 (6 Nov 2015 12:33:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Nov 2015 12:33:33 +0000 (UTC) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Nov 06 13:33:24 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 1ZugCm-0003P5-IY for guile-devel@m.gmane.org; Fri, 06 Nov 2015 13:33:20 +0100 Original-Received: from localhost ([::1]:38231 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZugCl-0005pk-Ka for guile-devel@m.gmane.org; Fri, 06 Nov 2015 07:33:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZugCh-0005pe-J2 for guile-devel@gnu.org; Fri, 06 Nov 2015 07:33:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZugCe-0005lx-C5 for guile-devel@gnu.org; Fri, 06 Nov 2015 07:33:15 -0500 Original-Received: from world.peace.net ([50.252.239.5]:55496) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZugCe-0005iA-7k; Fri, 06 Nov 2015 07:33:12 -0500 Original-Received: from [10.1.10.78] (helo=jojen) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1ZugCL-0001a9-SR; Fri, 06 Nov 2015 07:32:53 -0500 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: GNU/Linux 2.6.x X-Received-From: 50.252.239.5 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:17996 Archived-At: Andy Wingo writes: > On Thu 05 Nov 2015 11:29, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> 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. Yes, exactly. > 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. Unfortunately, I doubt this will be sufficient for LilyPond. The small example case in , which is apparently representative of how things are typically done in LilyPond, has structures like this: __________ __________ Objects in | | | | GC-managed | SMOB 1 | | SMOB 2 | heap |__________| |__________| | ^ | ^ .....................|...|.........................|...|.......... __v___|___ _________ __v___|___ Objects in | | | STL | | | normal heap |C++ object|--->|container|-->|C++ object| (not scanned |__________| |_________| |__________| by GC) The SMOB finalizers free the associated C++ objects below them. Now, suppose that none of the objects above are reachable, so both SMOBs are queued for finalization. Now suppose that SMOB 2 is finalized first, thus freeing the C++ object below it. Suppose further that we null out the SMOB 2 typecode. Now another GC occurs and the marker is called on SMOB 1. It's typecode has not yet been nulled, so the user-specified mark procedure is called. The mark procedure for SMOB 1 iterates over the STL container, and for each C++ object within, marks the corresponding SMOB via the upward pointer, in this case SMOB 2. Although SMOB 2's typecode has been zeroed out, the discovery of the fact is too late, because the (freed) C++ object below it has been referenced. As far as I can tell, this way of doing things depends on the old 1.8 GC finalization semantics, where all of the finalizers are called before the mutator resumes execution. Mark