From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: GC and stack marking Date: Wed, 21 May 2014 05:51:45 +0300 Message-ID: <83oayroncu.fsf@gnu.org> References: <83a9add91p.fsf@gnu.org> <8338g4bd7m.fsf@gnu.org> <537BA92D.50204@dancol.org> <83tx8knslw.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1400640721 17053 80.91.229.3 (21 May 2014 02:52:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 May 2014 02:52:01 +0000 (UTC) Cc: dancol@dancol.org, fabrice.popineau@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 21 04:51: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 1WmwdB-0005PS-B2 for ged-emacs-devel@m.gmane.org; Wed, 21 May 2014 04:51:49 +0200 Original-Received: from localhost ([::1]:56468 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmwdA-0003ho-U3 for ged-emacs-devel@m.gmane.org; Tue, 20 May 2014 22:51:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wmwd4-0003hf-Gm for emacs-devel@gnu.org; Tue, 20 May 2014 22:51:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wmwcz-0000jt-Jn for emacs-devel@gnu.org; Tue, 20 May 2014 22:51:42 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:42549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wmwcz-0000iH-BK for emacs-devel@gnu.org; Tue, 20 May 2014 22:51:37 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0N5W00I00KZ3VM00@mtaout25.012.net.il> for emacs-devel@gnu.org; Wed, 21 May 2014 05:48:31 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N5W00CEVL4VS460@mtaout25.012.net.il>; Wed, 21 May 2014 05:48:31 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 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:171976 Archived-At: > From: Stefan Monnier > Cc: Daniel Colascione , fabrice.popineau@gmail.com, emacs-devel@gnu.org > Date: Tue, 20 May 2014 18:03:51 -0400 > > > It's not a bug in GC. The memory management scheme that Fabrice wrote > > does not dump the heap (because doing that is problematic on Windows, > > and requires addition of a separate section to the executable, which > > then precludes its stripping, and has also other complexities). > > Instead, temacs uses a private fixed-address heap that is located in a > > static array, and whose memory is allocated by a replacement malloc > > function. So any address that points to memory allocated not in that > > array, but in the real heap provided by malloc from libc, cannot be > > safely dumped, because in the dumped Emacs it will point to some > > random location. > > OK, so why is the hash table allocated elsewhere then the other objects > (I understand why one might want to do that, but the question is about > what is different in the code in the case of this purify-flag hash-table > compared to other vectors/hashtables allocated during the dump). Because fixed-address heaps on Windows are limited to allocations whose size is at most 0x7f000, and one of the vectors allocated for a 70K hash-table is larger than that. > Is it just based on size? I.e. would the same problem show up if some > large vector were to be allocated (and not freed) before dumping? Yes. And not just large vectors, any large object (e.g., string). And that's what scared me, because I can always find a solution for the case I know of, but how to make this reliable in the face of future changes in Emacs? Anyway, it looks like Fabrice found a way to work around the above limitation, so I guess this issue is no longer such a big problem.