From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?Hans_=C3=85berg?= Newsgroups: gmane.lisp.guile.devel Subject: Re: Mark procedures and LilyPond Date: Sun, 24 Jan 2016 09:58:41 +0100 Message-ID: <4E6CB194-4F08-48FF-B64C-AB97A89B103D@icloud.com> References: <87vb9ihy6x.fsf@igalia.com> <87bnb891t8.fsf@gnu.org> <87ziyspp5d.fsf@pobox.com> <87io5ftij0.fsf_-_@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3117\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453642040 18955 80.91.229.3 (24 Jan 2016 13:27:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2016 13:27:20 +0000 (UTC) Cc: Andy Wingo , =?utf-8?Q?Ludovic_Court=C3=A8s?= , guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Jan 24 14:27:09 2016 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 1aNKhB-00036U-6U for guile-devel@m.gmane.org; Sun, 24 Jan 2016 14:27:09 +0100 Original-Received: from localhost ([::1]:60493 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNKh7-00050n-G4 for guile-devel@m.gmane.org; Sun, 24 Jan 2016 08:27:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNGWB-0004Ax-9g for guile-devel@gnu.org; Sun, 24 Jan 2016 03:59:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNGW8-0001y5-3y for guile-devel@gnu.org; Sun, 24 Jan 2016 03:59:31 -0500 Original-Received: from nk11p14im-asmtp001.me.com ([17.158.72.160]:34603) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNGW7-0001xz-U0; Sun, 24 Jan 2016 03:59:28 -0500 Original-Received: from [10.0.1.4] (h99n6-fre-d2.ias.bredband.telia.com [217.208.169.99]) by nk11p14im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O1G000TN8XULF50@nk11p14im-asmtp001.me.com>; Sun, 24 Jan 2016 08:58:46 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-01-24_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1601240171 In-reply-to: <87io5ftij0.fsf_-_@netris.org> X-Mailer: Apple Mail (2.3117) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 17.158.72.160 X-Mailman-Approved-At: Sun, 24 Jan 2016 08:27:03 -0500 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:18130 Archived-At: > On 6 Nov 2015, at 13:32, Mark H Weaver wrote: >> 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. Is Guile 2 doing its own finalization, not synced withe the Boehm GC?