From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: GC and stack marking Date: Tue, 20 May 2014 18:03:51 -0400 Message-ID: References: <83a9add91p.fsf@gnu.org> <8338g4bd7m.fsf@gnu.org> <537BA92D.50204@dancol.org> <83tx8knslw.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1400623466 3428 80.91.229.3 (20 May 2014 22:04:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 May 2014 22:04:26 +0000 (UTC) Cc: Daniel Colascione , fabrice.popineau@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 21 00:04:19 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 1Wms8w-0001Io-97 for ged-emacs-devel@m.gmane.org; Wed, 21 May 2014 00:04:18 +0200 Original-Received: from localhost ([::1]:55633 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wms8v-0001a6-Qk for ged-emacs-devel@m.gmane.org; Tue, 20 May 2014 18:04:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wms8l-0001Zw-Uy for emacs-devel@gnu.org; Tue, 20 May 2014 18:04:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wms8e-0006y1-G5 for emacs-devel@gnu.org; Tue, 20 May 2014 18:04:07 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:59630) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wms8W-0006x0-Jo; Tue, 20 May 2014 18:03:52 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVPO+KQe/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASpGYFqg0wh X-IPAS-Result: ArUGAIDvNVPO+KQe/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASpGYFqg0wh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="63438999" Original-Received: from 206-248-164-30.dsl.teksavvy.com (HELO pastel.home) ([206.248.164.30]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 May 2014 18:03:51 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id A2FD060126; Tue, 20 May 2014 18:03:51 -0400 (EDT) In-Reply-To: <83tx8knslw.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 20 May 2014 22:43:39 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.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:171970 Archived-At: > 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). 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? Stefan