From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.lisp.guile.bugs Subject: bug#19883: Smob's mark_smob has become unreliable in Guile 2.x Date: Sun, 01 Mar 2015 19:38:16 +0100 Message-ID: <877fv08sx3.fsf@fencepost.gnu.org> References: <87twyln70f.fsf@fencepost.gnu.org> <87zj7x5hxr.fsf@netris.org> <87385p9ggl.fsf@fencepost.gnu.org> <87vbik647i.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1425235156 18821 80.91.229.3 (1 Mar 2015 18:39:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Mar 2015 18:39:16 +0000 (UTC) Cc: 19883@debbugs.gnu.org To: Mark H Weaver Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sun Mar 01 19:39:08 2015 Return-path: Envelope-to: guile-bugs@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 1YS8lg-0000po-7M for guile-bugs@m.gmane.org; Sun, 01 Mar 2015 19:39:08 +0100 Original-Received: from localhost ([::1]:53580 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YS8lf-0001xh-Ga for guile-bugs@m.gmane.org; Sun, 01 Mar 2015 13:39:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35341) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YS8lb-0001xb-Rk for bug-guile@gnu.org; Sun, 01 Mar 2015 13:39:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YS8la-00037l-S2 for bug-guile@gnu.org; Sun, 01 Mar 2015 13:39:03 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58158) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YS8la-00037h-Ok for bug-guile@gnu.org; Sun, 01 Mar 2015 13:39:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YS8la-0001Uc-Hb for bug-guile@gnu.org; Sun, 01 Mar 2015 13:39:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <87twyln70f.fsf@fencepost.gnu.org> Resent-From: David Kastrup Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 01 Mar 2015 18:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19883 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 19883-submit@debbugs.gnu.org id=B19883.14252350995675 (code B ref 19883); Sun, 01 Mar 2015 18:39:02 +0000 Original-Received: (at 19883) by debbugs.gnu.org; 1 Mar 2015 18:38:19 +0000 Original-Received: from localhost ([127.0.0.1]:33523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YS8kt-0001TT-2v for submit@debbugs.gnu.org; Sun, 01 Mar 2015 13:38:19 -0500 Original-Received: from fencepost.gnu.org ([208.118.235.10]:36608 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YS8kr-0001TM-Oh for 19883@debbugs.gnu.org; Sun, 01 Mar 2015 13:38:18 -0500 Original-Received: from localhost ([127.0.0.1]:43915 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YS8kq-0005XD-OD; Sun, 01 Mar 2015 13:38:17 -0500 Original-Received: by lola (Postfix, from userid 1000) id 454E0E05DB; Sun, 1 Mar 2015 19:38:16 +0100 (CET) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7739 Archived-At: Mark H Weaver writes: > Finalizers are a huge can of worms. I suspect this is why Ludovic was > encouraging you to avoid them entirely, but I agree that we need to > find a way to make them work for when they are needed. Again, LilyPond does not really have an option to avoid finalizers (free_smob action): the C++ class instances associated with smobs contain STL containers, and the storage for those is allocated separately on the heap. Running the destructor of the C++ class instance (which is the basic finalization action done when calling the delete operator on the C++ class instance) will then also destruct the STL container, freeing all memory associated with _that_. We don't have control over the storage layout of the STL templates. While one could allocate them using a separate allocation template parameter, that may be a C++11 feature. And it would really complicate the code. Moving all of the smobification stuff into a few template classes has actually locked up our release process for almost a year: 2.19.15 was released in September, 2.19.16 is currently being uploaded. The release-building crosscompiling environment had to be updated to a newer GCC version to accept the templated code, and that GCC reason had new dependencies and needed to be bootstrapped with a C++ rather than a C compiler. And the person who has run the release process the last few years was not actually a programmer. > The mark functions can ensure that in your Family class, the children > will be marked even though the parent->child pointers point directly > to the C++ object. However, whenever the root of the tree is not > protected by 'scm_gc_protect_object', the SCM value of that root must > be visible to the GC, in order to cause the user-specified 'mark' > function to be called in the first place. > > It should be noted that for any particular C++ class, another > alternative is to arrange for instances of that class to be allocated > using 'scm_gc_malloc', as Ludovic suggested. If you do that, then it > would suffice to have a GC-visible pointer to instances of that class, > which might make your life easier. Again: a lot of smobified C++ structures contain STL containers that have their separate allocation that can easily have pointers to C++ structures associated with smobs again that need to be marked. At any rate: since LilyPond can eat a significant ratio of the entire memory space on 32bit machines, I consider it prudent not to have basically all of that scanned by the conservative garbage collector since that would significantly increase the number of false positives when marking. And we are talking about an advertised GUILE feature after all. With regard to "making our life easier": it's a sunk cost since all the work has obviously been done for GUILEv1 already. -- David Kastrup