public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Neumann <tneumann@users.sourceforge.net>
To: Richard Biener <richard.guenther@gmail.com>
Cc: David Edelsohn <dje.gcc@gmail.com>,
	Florian Weimer <fweimer@redhat.com>,
	GCC Development <gcc@gcc.gnu.org>
Subject: Re: performance of exception handling
Date: Tue, 12 May 2020 09:30:30 +0200	[thread overview]
Message-ID: <8cc4bfb6-cf9a-7644-bd69-ba8d328f4dcf@users.sourceforge.net> (raw)
In-Reply-To: <CAFiYyc1eFQCW-aZMetgM3gmh0LBHU_r12pQCCF2yP2W4ga0bwA@mail.gmail.com>

> Some people use exceptions to propagate "low memory" up which
> made me increase the size of the EH emergency pool (which is
> used when malloc cannot even allocate the EH data itself) ...
> 
> So yes, people care.  There absolutely has to be a path in
> unwinding that allocates no (as little as possible) memory.

note that I would not allocate at all in the unwinding path. I would
allocate memory when new frames are registered, but unwinding would be
without any allocations.

Of course there is a trade-off here. We could delay allocating the
lookup structures until the first exception occurs, in order to speed up
programs that never throw any exceptions. But that would effectively
force us to implement a "no memory" fallback, for exactly the reason you
gave, as something like bad_alloc might be the first exception that we
encounter.

Thomas

  reply	other threads:[~2020-05-12  7:30 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-11  8:14 Thomas Neumann
2020-05-11 10:40 ` Florian Weimer
2020-05-11 13:59   ` Thomas Neumann
2020-05-11 14:22     ` Florian Weimer
2020-05-11 15:14     ` size of exception handling (Was: performance of exception handling) Moritz Strübe
2020-05-12  7:20       ` Freddie Chopin
2020-05-12  7:47         ` Oleg Endo
2020-05-13  9:13           ` Jonathan Wakely
2020-05-12  9:16         ` size of exception handling Florian Weimer
2020-05-12  9:44           ` Freddie Chopin
2020-05-12 11:11             ` Jonathan Wakely
2020-05-12 11:17             ` Moritz Strübe
2020-05-12 11:29               ` Florian Weimer
2020-05-12 12:01                 ` Moritz Strübe
2020-05-12 11:07         ` size of exception handling (Was: performance of exception handling) Jonathan Wakely
2020-05-12 20:56           ` Freddie Chopin
2020-05-12 22:39             ` Jonathan Wakely
2020-05-12 22:48               ` Jonathan Wakely
2020-05-13  8:04                 ` David Brown
2020-05-12  9:03       ` size of exception handling Florian Weimer
2020-05-11 14:36   ` performance " David Edelsohn
2020-05-11 14:52     ` Florian Weimer
2020-05-11 15:12       ` David Edelsohn
2020-05-11 15:24         ` Florian Weimer
2020-05-12  6:08     ` Thomas Neumann
2020-05-12  7:15       ` Richard Biener
2020-05-12  7:30         ` Thomas Neumann [this message]
2020-05-12  9:01       ` Richard Sandiford
2020-05-13  1:13         ` Thomas Neumann

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

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

  git send-email \
    --in-reply-to=8cc4bfb6-cf9a-7644-bd69-ba8d328f4dcf@users.sourceforge.net \
    --to=tneumann@users.sourceforge.net \
    --cc=dje.gcc@gmail.com \
    --cc=fweimer@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /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.
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).