unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Jakub Jelinek via Libc-alpha <libc-alpha@sourceware.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: gcc-patches@gcc.gnu.org, libc-alpha@sourceware.org,
	Jason Merrill <jason@redhat.com>
Subject: Re: [PATCH 3/3] elf: Add _dl_find_eh_frame function
Date: Thu, 18 Nov 2021 14:43:03 +0100	[thread overview]
Message-ID: <20211118134303.GB2646553@tucnak> (raw)
In-Reply-To: <ed580138ca8b4c467f84f1131cfe627729588212.1635954168.git.fweimer@redhat.com>

On Wed, Nov 03, 2021 at 05:28:02PM +0100, Florian Weimer wrote:
> This function is similar to __gnu_Unwind_Find_exidx as used on arm.
> It can be used to speed up the libgcc unwinder.

I'm little bit worried that this trades the speed of exceptions for
speed of dlopen/dlclose and extra memory use in each process.
I admit I haven't been paying close attention to how many shared libraries
apps typically link against and how many dlopen/dlclose calls they do
in the last decade and half, but I'd think more applications don't use
exceptions compared to apps that do use them, and of many of those that do
use them don't use them for really exceptional cases, so speeding those
is a good thing.
So, I'd wonder, could this overhead be added lazily, when _dl_find_eh_frame
is called for the first time just take the rtld lock, prepare anything you
populate right now already from the process start up and every
dlopen/dlclose before the first _dl_find_eh_frame call and only since then
keep it updated on dlopen/dlclose?
Thus, for the expected majority of apps that aren't using exceptions at all
nothing would change for dlopen/dlclose overhead, while all but the first
_dl_find_eh_frame would be faster and with no locking?

	Jakub


  parent reply	other threads:[~2021-11-18 13:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03 16:27 [PATCH 0/3] Add _dl_find_eh_frame function for unwinder optimization Florian Weimer via Libc-alpha
2021-11-03 16:27 ` [PATCH 1/3] nptl: Extract <bits/atomic_wide_counter.h> from pthread_cond_common.c Florian Weimer via Libc-alpha
2021-11-15 19:24   ` Adhemerval Zanella via Libc-alpha
2021-11-18 13:19   ` Jakub Jelinek via Libc-alpha
2021-11-18 13:23     ` Florian Weimer via Libc-alpha
2021-11-03 16:27 ` [PATCH 2/3] elf: Introduce GLRO (dl_libc_freeres), called from __libc_freeres Florian Weimer via Libc-alpha
2021-11-15 19:28   ` Adhemerval Zanella via Libc-alpha
2021-11-03 16:28 ` [PATCH 3/3] elf: Add _dl_find_eh_frame function Florian Weimer via Libc-alpha
2021-11-16 12:42   ` Adhemerval Zanella via Libc-alpha
2021-11-17 13:40     ` Florian Weimer via Libc-alpha
2021-11-23 16:52       ` Adhemerval Zanella via Libc-alpha
2021-11-18 13:43   ` Jakub Jelinek via Libc-alpha [this message]
2021-11-18 14:09     ` Florian Weimer via Libc-alpha
2021-11-18 15:37   ` Jakub Jelinek via Libc-alpha
2021-11-18 16:28     ` Florian Weimer via Libc-alpha

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/libc/involved.html

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

  git send-email \
    --in-reply-to=20211118134303.GB2646553@tucnak \
    --to=libc-alpha@sourceware.org \
    --cc=fweimer@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jason@redhat.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).