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: Dumper problems and a possible solutions Date: Tue, 24 Jun 2014 16:24:47 -0400 Message-ID: References: <20140624171955.GS179@brightrain.aerifal.cx> <20140624194026.GT179@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1403641513 32693 80.91.229.3 (24 Jun 2014 20:25:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Jun 2014 20:25:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Rich Felker Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 24 22:25:06 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 1WzXH8-0004gu-Es for ged-emacs-devel@m.gmane.org; Tue, 24 Jun 2014 22:25:06 +0200 Original-Received: from localhost ([::1]:33694 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzXH7-00021G-Kq for ged-emacs-devel@m.gmane.org; Tue, 24 Jun 2014 16:25:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37629) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzXGx-0001uM-Um for emacs-devel@gnu.org; Tue, 24 Jun 2014 16:25:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzXGq-0002Kx-Ee for emacs-devel@gnu.org; Tue, 24 Jun 2014 16:24:55 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:11111) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzXGq-0002Kr-9x for emacs-devel@gnu.org; Tue, 24 Jun 2014 16:24:48 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABPCoMGg0rAPYEXF3SCJQEBAQECAVYjBQsLDiYSFBgNJC6HVgjSGReOHlwHhDgEqRmBaoNMIQ X-IPAS-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABPCoMGg0rAPYEXF3SCJQEBAQECAVYjBQsLDiYSFBgNJC6HVgjSGReOHlwHhDgEqRmBaoNMIQ X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="69434706" Original-Received: from 75-119-224-253.dsl.teksavvy.com (HELO ceviche.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 24 Jun 2014 16:24:47 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 403D466167; Tue, 24 Jun 2014 16:24:47 -0400 (EDT) In-Reply-To: <20140624194026.GT179@brightrain.aerifal.cx> (Rich Felker's message of "Tue, 24 Jun 2014 15:40:27 -0400") 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:172692 Archived-At: > Thanks for the feedback. Can you elaborate on how/why the hash > changes, and where it's stored that would need to be updated? When placing an object in a hash-table, the hashing function often just uses the address as "the hash value". So any hash-table that uses such a hash-function will need to be rehashed after relocation. > As far as the relocation, my impression is that it would just need to > be able to identify pointers in lisp objects (this is already possible > since the GC needs to do it, right?), and rewrite them to > (essentially) "static_lisp_heap + offset_of_pointed_to_object" when > writing the dump out as a C array. Yes, the GC already knows how to find the references that are inside Lisp objects, but there can also be references coming from global variables (for sure) or non-Lisp data-structures or maybe from the stack (not sure about those last two). > This is the xemacs "portable dumper" approach, and I believe it's > inferrior because it depends on being able to map back at the same > location. We could support relocation at mmap-time to solve this. Neither solution is clearly superior to the other, it just depends on you priority. For me, either way would be an improvement over what we have (tho, again, it might still depend on the constraints imposed by the need to perform relocation). Stefan