Re: Preview: portable dumper

[Daniel Colascione]

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
> 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.

> 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");
>   #endif
> -  sigaction (SIGABRT, &thread_fatal_action, 0);
> +  //sigaction (SIGABRT, &thread_fatal_action, 0);
>   #ifdef SIGPRE
>     sigaction (SIGPRE, &thread_fatal_action, 0);
>   #endif

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 
> interpreted
>   ;; 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.