From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.devel Subject: Question about mmap buffers Date: Fri, 25 Apr 2014 11:20:36 +0000 (UTC) Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1398424918 26709 80.91.229.3 (25 Apr 2014 11:21:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Apr 2014 11:21:58 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 25 13:21:51 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 1WdeCU-00026u-Ty for ged-emacs-devel@m.gmane.org; Fri, 25 Apr 2014 13:21:51 +0200 Original-Received: from localhost ([::1]:57212 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WdeCU-0008GE-H7 for ged-emacs-devel@m.gmane.org; Fri, 25 Apr 2014 07:21:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WdeBi-0007NW-Op for emacs-devel@gnu.org; Fri, 25 Apr 2014 07:21:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WdeBa-0004g8-IW for emacs-devel@gnu.org; Fri, 25 Apr 2014 07:21:02 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:57072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WdeBa-0004g4-Bl for emacs-devel@gnu.org; Fri, 25 Apr 2014 07:20:54 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WdeBV-0000Nz-WB for emacs-devel@gnu.org; Fri, 25 Apr 2014 13:20:50 +0200 Original-Received: from abo-126-219-68.trs.modulonet.fr ([85.68.219.126]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Apr 2014 13:20:49 +0200 Original-Received: from fabrice.popineau by abo-126-219-68.trs.modulonet.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Apr 2014 13:20:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 51 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 85.68.219.126 (Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:171627 Archived-At: I'm in the process of revamping memory allocation for Win32 and adding virtual memory allocation support for buffers. Reading the code in src/buffer.c, I wonder about the mmap_set_vars() function. This function sets the beginning of text address to NULL before dumping, and later in init_buffer() the same address is tested for being NULL, in which case the buffer memory is allocated. Why can't this be written as the Win32 code below: void init_buffer (void) { char *pwd; Lisp_Object temp; ptrdiff_t len; #ifdef USE_MMAP_FOR_BUFFERS { /* When using the ralloc implementation based on mmap(2), buffer text pointers will have been set to null in the dumped Emacs. Map new memory. */ struct buffer *b; #ifdef WINDOWSNT /* Who cares: no buffer can be dumped with a meaningful address. We can as well force their values at NULL here. */ FOR_EACH_BUFFER (b) { b->text->beg = NULL; enlarge_buffer_text (b, 0); } #else FOR_EACH_BUFFER (b) if (b->text->beg == NULL) enlarge_buffer_text (b, 0); #endif } #endif /* USE_MMAP_FOR_BUFFERS */ and forget about the mmap_set_vars() function? If this is correct and a change along these lines could be applied, that would slightly simplify my patch to come. Thanks for any comments, Fabrice