unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Pip Cet <pipcet@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: master d582356: * src/fns.c (Frandom): Handle bignum `limit`s
Date: Sun, 7 Mar 2021 13:27:01 +0000	[thread overview]
Message-ID: <CAOqdjBdw5L+h7V4LH=FHEcOStGMnOVK_koaEZ7Ktfe7p=jTxHQ@mail.gmail.com> (raw)
In-Reply-To: <838s70wdb5.fsf@gnu.org>

On Sat, Mar 6, 2021 at 2:46 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Sat, 6 Mar 2021 13:22:10 +0000
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> >
> > > > So I'm not sure whether code_conversion_save is allowed to call Lisp.
> >
> > > I'd rather it didn't, for more than one reason.  But we can side-step
> > > this by making Fgenerate_new_buffer_name use random-fixnum, which is
> > > still a pure-C implementation.
> >
> > Here's a patch which makes it use get_random() directly.
>
> Thanks, maybe add a comment explaining the need for the do-while loop
> in generate-new-buffer-name.

I received some very intelligent suggestions on how to improve the
code, will follow up with a better patch (unless the anonymous
benefactor beats me to it, of course :-) ).

> > Actually, I think it would be best to have these restrictions
> > represented in the code. I see two ways of doing that:
> >
> > 1. Have FUNCTION_MAY_GC etc. translate into a GCC attribute in debug
> > builds so we can statically check that a function that says it never
> > calls GC doesn't call a function that says it may call GC.
> > 2. Have a statement at the beginning of non-GCing functions which sets
> > a flag that is then checked by garbage-collecting functions, so that
> > we may dynamically check this.
> >
> > (1) seems easy to implement, but has a high rate of false negatives as

"Seems". If you have a computer fast enough and enough RAM to actually
compile emacs with -flto -fanalyzer -fdump-analyzer-json. I don't.

> > many functions are safe to call from non-GCing functions as long as
> > the arguments are correct.
> > (2) is difficult to implement, and would only trigger at runtime.
> >
> > So I say we should do (1) in preference to (2), but maybe we should do both.
>
> I don't think I understand how will we know which function says it
> never calls GC.

By tagging it in the source code?

> And the FUNCTION_MAY_GC attribute, even if applied to
> the lowest-level functions that actually call maybe_gc, would be a
> maintenance headache because we do change this from time to time.  So
> we'd need something that checks the attribute's accuracy at compile
> time, otherwise the attribute will bitrot.

Indeed. We should walk the call graph and determine which basic blocks
end up (potentially) calling GC, which is what I set out to do with
-fanalyzer but can't continue working on because it's too slow for
Emacs...

> For the same reasons, I don't see how (2) can be done in practice.

Sorry, I don't understand.  We'd have

void
f (void)
{
  DONT_CALL_GC ();
  g();
}

void
g (void)
{
  maybe_gc ();
}

and that would throw a runtime error because maybe_gc checks the flag
set by DONT_CALL_GC.

I don't think that would be too hard to maintain; would it?

(It would, alas, throw the error only at runtime (or -fanalyzer time,
potentially), and implementing it wouldn't be entirely trivial because
of stack unwinds, but doable).

What I'd like to know is whether something like this is worth pursuing
at all, and that mostly depends on whether people are willing to build
with --enable-checking=nogc once in a while and fix any assertion
errors that pop up.

Pip



  reply	other threads:[~2021-03-07 13:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210305170955.27732.27579@vcs0.savannah.gnu.org>
     [not found] ` <20210305170957.AF99920E1B@vcs0.savannah.gnu.org>
2021-03-05 19:42   ` master d582356: * src/fns.c (Frandom): Handle bignum `limit`s Pip Cet
2021-03-05 19:56     ` Stefan Monnier
2021-03-05 20:13       ` Pip Cet
2021-03-05 20:34         ` Stefan Monnier
2021-03-06  7:42       ` Pip Cet
2021-03-06  8:44         ` Eli Zaretskii
2021-03-06  9:44           ` Pip Cet
2021-03-06 10:56             ` Eli Zaretskii
2021-03-06 13:22               ` Pip Cet
2021-03-06 14:45                 ` Eli Zaretskii
2021-03-07 13:27                   ` Pip Cet [this message]
2021-03-07 14:04                     ` Eli Zaretskii
2021-03-07 14:21                       ` Pip Cet
2021-03-07 15:22                         ` Eli Zaretskii
2021-03-07 17:23                           ` Pip Cet
2021-03-07 17:47                             ` Eli Zaretskii
2021-03-07 18:37                     ` Stefan Monnier
2021-03-07 19:54                       ` Andrea Corallo via Emacs development discussions.
2021-03-07 19:55                       ` Pip Cet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOqdjBdw5L+h7V4LH=FHEcOStGMnOVK_koaEZ7Ktfe7p=jTxHQ@mail.gmail.com' \
    --to=pipcet@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).