This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Excessive calls to iterate_phdr during exception handling
- From: Torvald Riegel <triegel at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Thu, 30 May 2013 15:00:40 +0200
- Subject: Re: Excessive calls to iterate_phdr during exception handling
- References: <51A3DC25 dot 90401 at cs dot utoronto dot ca> <51A4F2BD dot 2090900 at gmail dot com> <51A4F7B6 dot 7090307 at redhat dot com> <1369905668 dot 16968 dot 8660 dot camel at triegel dot csb> <20130530092825 dot GA1493 at tucnak dot redhat dot com>
On Thu, 2013-05-30 at 11:28 +0200, Jakub Jelinek wrote:
> On Thu, May 30, 2013 at 11:21:08AM +0200, Torvald Riegel wrote:
> > On Tue, 2013-05-28 at 20:30 +0200, Florian Weimer wrote:
> > > On 05/28/2013 08:09 PM, VÃclav Zeman wrote:
> > >
> > > > If the bottleneck is really in glibc, then you should probably ask them
> > > > to fix it. Could the mutex be changed rwlock instead?
> > >
> > > rwlocks don't eliminate hardware contention, so I doubt they'd be a win
> > > here.
> >
> > Indeed. Reader-writer locks guarantee the critical section, even the
> > readers, that they run mutually exclusive with writers. So whatever you
> > do while holding the lock, the protected data won't change. That
> > restricts what we can do, because we need to actively prevent writers
> > from doing things, which means making your read operation visible to
> > others (unless you can stop the writers in some other funny ways).
> >
> > However, we only seem to need an atomic snapshot here AFAIU, in which
> > case we can do stuff like reading the data optimistically, verifying
> > that we read consistent data, and retrying if we didn't.
>
> Please look at the mail I've posted in this threads, there are lots of ABI
> complexities involved and for many solutions it would require to change both
> glibc and gcc (the latter conditionally on glibc), which makes it a long
> term process.
I did read those emails (but didn't actually look at the dynamic loader
code). What I was commenting on is that there are other ways to
synchronize in case we need an atomic snapshot (if it's such a case),
which are probably more efficient than a lock. I wasn't at all
commenting on whether it would be simple to make such a change, or even
worth doing it for the potential performance gain.