Re: Larger GC thresholds for non-interactive Emacs

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3503 bytes --]

On Thu, Jun 23, 2022 at 3:09 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Lynn Winebarger <owinebar@gmail.com>
> > Not that I don't enjoy trawling through old threads in the emacs-devel
> archive
> > (searching for mmap led to a thread from the introduction of the
> portable dumper),
> > but it would be a lot easier if there were design notes somewhere
> recording
> > the rationale of the decisions reflected in the current code.
>
> We lack someone in the role of the "project historian", who would then
> summarize and publish the design discussions in the form of such
> notes.  Volunteers are most welcome.
>

It's not the discussion (or history) per se, but the factors that decided
the current
design choices.  An example would be the #ifdef DOUG_LEA_MALLOC blocks in
lisp_align_malloc
of alloc.c that prevent allocating via mmap.  So far what I've read
indicates
that step is there to enable dumping by unexec (assuming I've understood
correctly).
Ideally there would be a design note (possibly generated from comments,
possibly free standing)
that would explain what the purpose of the restriction is, so you could
tell if it's still
relevant, and any negative impacts it has.  Also, if there are plans to
remove it at
some point, what (if any) the requirements/test for removing it would be,
etc.  By "it",
I mean any hypothetical design point, not just this particular one.
Alternative designs could also be discussed along with the factors that led
to their rejection, if it was significant enough.
Now, those could be derived from mailing list discussions, but I wouldn't
consider them
"history".  Per subsequent mails in this thread, if a developer or code
reviewer made
a practice of citing particular mail messages (or even other sources), some
extraction
process might even be automated, but then there would be the question of
copyright
assignment.  It would help if there were some taxonomy of features/design
points for
reference.  Is the bug database being used for that?

Actually, a good example (even though it's more post facto description than
prospective
design & cost-benefit tradeoff analysis) would be
https://github.com/rocky/elisp-bytecode
That is really useful documentation that would ideally be in the emacs docs
or etc directory.
Andrea's development log and paper on the compiler are another example.
The development log would benefit (in terms of use as design notes) from
de-chronologizing
them, figuring out the right taxonomy of the various topics, and gathering
the material accordingly.

I put in a request to assign@gnu.org a few days ago, but I have not
received any response yet.


>
> > The best I can do now
> > is comb through the arguments on the list (and maybe in the bug
> tracker?) and
> > try to guess which points ended up getting reflected in the code.
>
> A better method is to use Git logs to find when the GNU/Linux build
> stopped using mmap, and then search the archives around that time.
>
> > I will say jemalloc appears to have a lot of heap profiling bells and
> whistles.
>
> AFAIU, so does glibc.  Some of them where mentioned in the discussions
> you already unearthed, AFAIR.
>

I figured it would.  jemalloc's maintainers just spend a lot of effort
highlighting those features in the
documentation.  I wouldn't be surprised if it was 3/4 of the material on
the package's site
is dedicated to how to use jemalloc's profiling for debugging or optimizing
memory allocation in the calling program.  It makes an impression.

Lynn

[-- Attachment #2: Type: text/html, Size: 4654 bytes --]