[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Preview: portable dumper

From: Daniel Colascione
Subject: Re: Preview: portable dumper
Date: Thu, 29 Mar 2018 08:31:26 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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.

Some minor

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.

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.

I don't understand this hunk in sysdep.c:

@@ -2138,7 +2149,7 @@ init_signals (bool dumping)
  #ifdef SIGUSR2
    add_user_signal (SIGUSR2, "sigusr2");
-  sigaction (SIGABRT, &thread_fatal_action, 0);
+  //sigaction (SIGABRT, &thread_fatal_action, 0);
  #ifdef SIGPRE
    sigaction (SIGPRE, &thread_fatal_action, 0);

Thanks; I'll clean that up. That's left over from the demand paging experiment.

Similarly, this hunk in pcase.el:

@@ -63,6 +63,7 @@
  ;; FIXME: Now that macroexpansion is also performed when loading an 
  ;; file, this is not a real problem any more.
  (defconst pcase--memoize (make-hash-table :weakness 'key :test 'eq))
+;; (defconst pcase--memoize (make-hash-table :test 'eq))
  ;; (defconst pcase--memoize-1 (make-hash-table :test 'eq))
  ;; (defconst pcase--memoize-2 (make-hash-table :weakness 'key :test 'equal))

Thanks for catching that.

Are those two intentional?

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.

Apart from that, there appear to be no disadvantages for people who
prefer to continue using unexec. Is that correct?

That's correct.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]