From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Thu, 10 Jul 2014 19:21:16 +0200 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1405012890 5374 80.91.229.3 (10 Jul 2014 17:21:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Jul 2014 17:21:30 +0000 (UTC) Cc: Emacs development discussions To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 10 19:21:24 2014 Return-path: Envelope-to: ged-emacs-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 1X5I26-00041Y-MJ for ged-emacs-devel@m.gmane.org; Thu, 10 Jul 2014 19:21:22 +0200 Original-Received: from localhost ([::1]:39195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5I26-0001Wg-7U for ged-emacs-devel@m.gmane.org; Thu, 10 Jul 2014 13:21:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5I23-0001WX-K8 for emacs-devel@gnu.org; Thu, 10 Jul 2014 13:21:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X5I22-0004lg-ED for emacs-devel@gnu.org; Thu, 10 Jul 2014 13:21:19 -0400 Original-Received: from mail-lb0-x22c.google.com ([2a00:1450:4010:c04::22c]:52434) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5I22-0004lY-5e for emacs-devel@gnu.org; Thu, 10 Jul 2014 13:21:18 -0400 Original-Received: by mail-lb0-f172.google.com with SMTP id c11so6536471lbj.3 for ; Thu, 10 Jul 2014 10:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3zue9jPFARWK8CBNVcHFd6naZXGEiq5kEMjZImCCNSU=; b=v+s/+aWpfr/koegSLQ3aYKhIikzpSAri6bUqPajUh+01ZdtuEQk5pupmgjrGHE1QzP M02leSm9kq6fpNpjK3Xf0z3FUFXndc0HRGTwbc17NFgrD7yZkbUFFv2wjFHgotlptQ44 esEKmM4sGqdnEDDtb/7qr5OfrhEoSr98OAjy593OBoAcVSzKz8+W10goIAD4EJmmDu43 5cPsVbG0McI5B1A/z5V6Dhriv+eisoz2KtYDibj9Z+ra4Om2eWTMAVvuWhPxkkYFbhO3 JZUrmzCXH5SY2tGt0P8fsntJ7TPuyCcdO09qLFipMUfc+07tkSk4IvfVaiDfY3vJ7xfN 9tvQ== X-Received: by 10.112.129.9 with SMTP id ns9mr6766254lbb.23.1405012877101; Thu, 10 Jul 2014 10:21:17 -0700 (PDT) Original-Received: by 10.114.77.202 with HTTP; Thu, 10 Jul 2014 10:21:16 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: 89WFyYUSWXZ4jIq4YCtKZ1Ud1IU X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::22c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172936 Archived-At: On Thu, Jul 10, 2014 at 12:18 AM, Stefan Monnier wrote: > You could change its handling of PVEC_SUBR such that it calls itself > recursively on the `doc' field and then make sure the VECTOR_MARKED_P bit > gets reset to false in gc_sweep. I understand that marking a symbol which is bound to a subr means we have to mark the subr i.e. the doc field since we can't free a subr. But why do we need to do something else? The doc string being either a cons, an int or a string it will be automatically handled in the respective sweep_xxx functions. There are no global list of subr that can be swept AFAIK. I've only made the mark_object() recursive call. Getting a module documentation still doesn't work but at least the conses are valid now. > Or maybe force those `doc' references to be kept alive by adding > globally reachable references to them (e.g. have a global list of all > the cons cells you ever added to such a `doc' field, and then > `staticpro' that list). The first solution is better IMHO, it's more intrusive but it limits the scope of the problem to the GC.