From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Thu, 29 Mar 2018 16:15:44 +0000 Message-ID: References: <1775923222.898447.1518559575706@mail.libero.it> <277032065.898859.1518560883271@mail.libero.it> <1901861254.379742.1519646632018@mail.libero.it> <546679939.469612.1522307541367@mail.libero.it> <3b0dd2cd-fd15-c017-7249-7ae2fa567556@dancol.org> <87zi2rqkzi.fsf@gmail.com> <419cb2c8-0c26-104a-bab5-ba67ad148b88@dancol.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1522340146 11648 195.159.176.226 (29 Mar 2018 16:15:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Mar 2018 16:15:46 +0000 (UTC) Cc: rpluim@gmail.com, Angelo Graziosi , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 29 18:15:41 2018 Return-path: Envelope-to: ged-emacs-devel@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 1f1aDF-0002vA-3P for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 18:15:41 +0200 Original-Received: from localhost ([::1]:37313 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1aFI-0000AL-Hs for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 12:17:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41888) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1aDz-00007d-F5 for emacs-devel@gnu.org; Thu, 29 Mar 2018 12:16:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1aDy-0005eL-AU for emacs-devel@gnu.org; Thu, 29 Mar 2018 12:16:27 -0400 Original-Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:53104) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f1aDy-0005dg-3d for emacs-devel@gnu.org; Thu, 29 Mar 2018 12:16:26 -0400 Original-Received: by mail-wm0-x22d.google.com with SMTP id l9so11797012wmh.2 for ; Thu, 29 Mar 2018 09:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FiajnGEy/5zNvbl2m9qhuhsBPQzvKF3NSVWHktvNo9Q=; b=ujxT9YdkGveCTeKa/JVDxtNUcLDDvdRi4m0umKJqtK98GwiWxjQwjfACHX+ImhyFa5 aBz8Ms686rPkQM6jH3KtT4+VmTJkpBhRnU3FPEkKrcRjCZpxXF98KRetDlvpiJ2R5TFE X2d/TIthZ867ZVjDTYQigOEGJWt69xyLfisqCP8z+fjGZyHj+CgXsL9VfqjkCr92mrBt xVOtrlYu3cVDBPt29P+BzMtQ94Ync4pIyDhjesi00URBhx/Mgd9eNc6HO5n1fxet+x2v 3nzHxu03BLGJl3NtoLVkqLJWeCzZwIYQcvN61m7+S5RZFVtmKPlIhh021E0NDemHEUBp XDAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FiajnGEy/5zNvbl2m9qhuhsBPQzvKF3NSVWHktvNo9Q=; b=PghsXP5Y7domg/0VdjVuOvBMAJWOrqedLSYm3G4Zw3ZDJ2OZ9TgqK0hJczQy9d9JNi bRFAr3FauLRBchkHcrfZoFuxI/k0uef4QGxadUhXvOpswS3YPXCVHvhRj07hxjrxjCGF Yo7wdm63DrlveUo7aIIITROmQcaDXaF2SktixmqX4Cgyrp8fVtDY60hgTf9A9ZN90AFU CPV21DO8gsHDc4vi2SkYgXYQurWRVcf9QSAL/MD2Ux8b0cihmzviLzZxEiG/i7Yp7aSs 2XxGjEuPX4qVBItu5vbaA5ejoxl0FBcgUExYtTCFoGQSS0Xw/goiUQDox/OHVy8W7Yba RMPQ== X-Gm-Message-State: AElRT7Hz/7fSVd5YSKJwk+rgHcK9eUWSbQWNRub5QQPt59oxBJoUKoJ9 JrNFBfnJBU7wZYZ8g1iWSqch/LUAf5yb3kmpNg8y4A== X-Google-Smtp-Source: AIpwx4/3POAGhdUEVyqUzT7Jzofg518MokIxXHO1bZT3sDchd/+b3ddpkNODuPfMu0gsIrtEYWtl3jOy1daKHoCrBb0= X-Received: by 10.80.231.13 with SMTP id a13mr8098469edn.212.1522340185096; Thu, 29 Mar 2018 09:16:25 -0700 (PDT) Original-Received: by 10.80.129.230 with HTTP; Thu, 29 Mar 2018 09:15:44 -0700 (PDT) In-Reply-To: <419cb2c8-0c26-104a-bab5-ba67ad148b88@dancol.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:224160 Archived-At: On Thu, Mar 29, 2018 at 3:31 PM, Daniel Colascione wrote: > On 03/29/2018 06:35 AM, Pip Cet wrote: >> I've just skimmed the diff, and I think the change is a significant >> improvement, and will help with my GC experiments even though I'm >> probably never going to be able to use the portable dumper. > > > Why not? I eventually want to remove unexec entirely. No objections to removing unexec, as long as temacs remains an option :-) I haven't thought about dumping/restoring SpiderMonkey state, but as it's hairy enough to get things working with setjmp(), I'd rather not worry about it now. I do have a half-finished (working, but not thoroughly tested) unexec for asm.js, too, which sped things up somewhat, but I don't see why the portable dumper wouldn't work there, too. > >> Some minor >> comments: >> >> it is not clear to me why some staticpro's are moved to happen after >> the initialisation of the variable and some aren't. > > > The code has always been a bit unclear about that; we don't GC that early, > so it doesn't really matter- -- but if we did, we'd be saved by nil being > all zero these days. Well, Qnil isn't all zero (or even constant) here, and I do GC unpredictably, though hopefully never that early; I'm still safe if the staticpro goes first: the all-zero value, representing 0.0, is fine for GC. >> Maybe we should >> change staticpro to have a >> void staticpro(Lisp_Object *ptr, Lisp_Object initial_value); >> signature and save some lines of code? > > > Sometimes the value from .data is perfectly good though, and at that point, > the initial_value setting would be a waste. ... as are explicit Qnil initializations, in general. So inline void staticpro(Lisp_Object *ptr, Lisp_Object initial_value) { assume(*ptr == Qnil); real_staticpro(ptr); if (initial_value != Qnil) *ptr = initial_value; } would actually reduce code size. But, again, it'd be better to merge first, then optimize such minor things. >> I would vaguely prefer if "pdumper" names were limited to the actual >> pdumper implementation, and "dumper" names were used instead in code >> that does not depend on the implementation of the dumper. So we'd have >> dumper_object_p(), defined to false if there's no dumper, and >> pdumper_object_p otherwise. > > > I'd rather not do a big renaming at this point. Nothing stops someone doing > cleanup work post-merge if sufficiently motivated. Agreed. >> Apart from that, there appear to be no disadvantages for people who >> prefer to continue using unexec. Is that correct? > That's correct. Thanks!