From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Marko Rauhamaa Newsgroups: gmane.lisp.guile.user Subject: Re: Guile bugs Date: Fri, 21 Jul 2017 11:27:41 +0300 Message-ID: <87ziby6vpe.fsf@elektro.pacujo.net> References: <87lgtajpkc.fsf@web.de> <87h8y7ruuz.fsf_-_@gnu.org> <877ez384eu.fsf@elektro.pacujo.net> <87k2333qx9.fsf@gmail.com> <87pocvc5ya.fsf@elektro.pacujo.net> <87poculu2v.fsf@gnu.org> <87inimd9yy.fsf@elektro.pacujo.net> <87k232cu3p.fsf@netris.org> <877ez2co3j.fsf@elektro.pacujo.net> <20170721091608.6585de97@bother.homenet> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1500625690 28350 195.159.176.226 (21 Jul 2017 08:28:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 21 Jul 2017 08:28:10 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: guile-user@gnu.org To: Chris Vine Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Jul 21 10:28:05 2017 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dYTI2-0006qJ-HI for guile-user@m.gmane.org; Fri, 21 Jul 2017 10:28:02 +0200 Original-Received: from localhost ([::1]:41678 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dYTI6-0004rw-Dm for guile-user@m.gmane.org; Fri, 21 Jul 2017 04:28:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dYTHl-0004re-9M for guile-user@gnu.org; Fri, 21 Jul 2017 04:27:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dYTHk-0004gT-Dn for guile-user@gnu.org; Fri, 21 Jul 2017 04:27:45 -0400 Original-Received: from [2001:1bc8:1a0:5384:7a2b:cbff:fe9f:e508] (port=44274 helo=pacujo.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dYTHk-0004fP-5v for guile-user@gnu.org; Fri, 21 Jul 2017 04:27:44 -0400 Original-Received: from elektro.pacujo.net (192.168.1.200) by elektro.pacujo.net; Fri, 21 Jul 2017 11:27:41 +0300 Original-Received: by elektro.pacujo.net (sSMTP sendmail emulation); Fri, 21 Jul 2017 11:27:41 +0300 In-Reply-To: <20170721091608.6585de97@bother.homenet> (Chris Vine's message of "Fri, 21 Jul 2017 09:16:08 +0100") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2001:1bc8:1a0:5384:7a2b:cbff:fe9f:e508 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:13964 Archived-At: Chris Vine : > On Fri, 21 Jul 2017 09:15:28 +0300 > Marko Rauhamaa wrote: >> The closest I could find is: >> >> * Static data region(s). In the simplest case, this is the region >> between DATASTART and DATAEND, as defined in gcconfig.h. However, >> in most cases, this will also involve static data regions >> associated with dynamic libraries. These are identified by the >> mostly platform-specific code in dyn_load.c. >> >> But that doesn't clearly state if mmapped regions are in or out. I >> would have assumed they were in. > > Since the C runtime does not store static variables in mmapped memory, > I would have assumed the opposite. I use libgc in non-Guile code. If mmapped areas are not considered for GC, I'll have to take special care. I had assumed libgc simply introspects the process's memory map and traverses anything reachable. After all, the process might be also using a secondary memory allocator based on mmap. What if you do place pointers in a mmapped region? > There is also some information at https://www.gnu.org/softwa > re/guile/manual/html_node/Garbage-Collection.html#Garbage-Collection > That states that the areas that the garbage collector scans for live > objects are the areas where global and other static variables are > placed, local variables (including function arguments and registers), > and heap memory allocated by scm_gc_malloc() (but not memory allocated > by scm_gc_malloc_pointerless() or by malloc() and cognates). Which doesn't say anything explicit about mmap. Anyway, I suspect a bytearray is guaranteed to be pointerless and could be used for the desired kind of mass storage in RAM. It all hinges on the efficiency of encoding and decoding objects. As much as possible, I would like to stay in Scheme-land. Marko