kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64

[Konstantin Belousov]

The following reply was made to PR kern/131597; it has been noted by GNATS.

From: Konstantin Belousov <kostikbel at gmail.com>
To: Jilles Tjoelker <jilles at stack.nl>
Cc: bug-followup at FreeBSD.org, John Baldwin <jhb at freebsd.org>,
        guillaume at morinfr.org, theraven at freebsd.org
Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD
 7.1/amd64
Date: Sun, 30 Jun 2013 06:12:32 +0300

 --suMD1gxl821dzEEX
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Sat, Jun 29, 2013 at 11:53:35PM +0200, Jilles Tjoelker wrote:
 > On Fri, 28 Jun 2013 20:45:38 +0300, Konstantin Belousov wrote:
 > > On Fri, Jun 28, 2013 at 01:38:39PM -0400, John Baldwin wrote:
 > > > On Friday, June 28, 2013 1:17:21 pm Konstantin Belousov wrote:
 > > > > On Fri, Jun 28, 2013 at 08:47:55AM -0400, John Baldwin wrote:
 > > > > > Looking at this again, the patch committed in 178807 is just
 > > > > > wrong and should be reverted.  There is no state in rtld that
 > > > > > needs to be protected via a write lock.  GCC is too lazy to use
 > > > > > their own locking to protect shared state between threads and
 > > > > > wants the runtime linker to enforce this.  Their justification
 > > > > > that glibc doesn't allow concurrent execution of this isn't a
 > > > > > valid excuse.  For an API like this that just walks a list and
 > > > > > invokes a callback, if the callback manipulates shared state
 > > > > > owned by the caller, the caller should be responsible for
 > > > > > sychronizing access to it, not rtld!
 >=20
 > > > > > Instead I think we should apply the patch in the original GCC
 > > > > > bug to our in- tree GCC and to our GCC ports.  This should
 > > > > > remove the sigprocmask calls and not penalize other users of
 > > > > > dl_iterate_phdr() for GCC's poor behavior.
 >=20
 > > > > In other words, we should become knowingly incompatible with the st=
 ock
 > > > > GCC and with other consumers of dl_iterate_phdr(), like libunwind ?
 > > > > E.g. libunwind ability to unwind from the signal handler relies on
 > > > > this behaviour.
 >=20
 > > > Does libunwind depend on rtld single-threading to lock state shared
 > > > with other threads?  If it does it should manage that itself.  If
 > > > GCC and/or libunwind want to share arbitrary state between threads,
 > > > or protect state from being accessed by a signal handler, then GCC
 > > > and/or libunwind should manage that.  rtld can't possibly (and
 > > > shouldn't) know the rules about how that state that is private to
 > > > GCC/libunwind is managed.
 >=20
 > > libunwind depends on the dl_iterate_phdr() signal-safety.
 >=20
 > > > What if you had a consumer of this that wanted to access the state
 > > > outside of the callback?  Then it already has to manage all the
 > > > locking itself to be safe anyway.
 >=20
 > > > Put another way, requiring dl_iterate_phdr() to providing locking
 > > > for consumers would be equivalent to code assuming that C++'s
 > > > for_each() template in <algorithm> provided locking to callers.
 > > > That is entirely upside-down.
 >=20
 > > I think I should revive the fast sigprocmask patch.
 >=20
 > We could add a version of dl_iterate_phdr that does not call
 > sigprocmask() and use it in patched GCC/libunwind/etc. The patched GCC
 > and libunwind can then avoid the sigprocmask call (possibly at the cost
 > of less efficient caching) while unpatched GCC and libunwind continues
 > to work.
 As I said, libunwind relies on the signal blocking behaviour to be able
 to unwind from the signal handler.
 
 >=20
 > I am a bit concerned, though, that this is only needed for the
 > unthreaded programming environment. libthr has an efficient method for
 > postponing signals that avoids system calls. Moving that mechanism to
 > libc, although it is a bit hard, may be an option.
 
 Well, the right answer then is, in fact, to merge libc and libthr.
 I implemented ELF filters as the first required step, but did not
 progressed the task further.
 
 IMO the merge is mostly mechanical, the complication is due to the fact
 that the work should be done in branch and takes a lot of time. As
 result, the libc and libthr changes during development are conflicting
 and have to be constantly resolved.
 
 --suMD1gxl821dzEEX
 Content-Type: application/pgp-signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.20 (FreeBSD)
 
 iQIcBAEBAgAGBQJRz6IfAAoJEJDCuSvBvK1BMyMP/Agnvo15YjGSs3Vj3Dqy/ffE
 o1Pq3xxRSry2E2IUI04OlHR4223LMeUx/oSg5uNoZog3n0V7hWB2jYI3Kyo2n6cH
 0AP6kQTezqnrq8jDsEKeaUZIPqqZ7O1H86pnBNamMmUHfQ7+MzbCpt+D9EXPGmsR
 It5xn3SNFCvzqi8brsJXEir4XMQjFedj07BDjPlQsXsqqLkpDegHsJ7VCBpVStfn
 I4IAWwzJ8oiGrnEsRFKaYq1HvGvQp2S51WnzUt2Uv6PCpz0pAfRoIeYV8az879OQ
 33xU8eMceds8FnOtPsiIrNL/OO70tMPD2QHEFVLS5ltM/NTmabnFPl/5/2nMDZXs
 rik3A3DjjDMbHBENc1nU/2YQZertFsCrsOLb6h5sYS66NjF4yhPdq9EQtFoECOcZ
 Y73YhZgQxdTxIHNXCsRbWDzc2fMnhp5sDSfKtBBzJDV3u1lfYiSFk9FO/4LpK/lJ
 eyu4waFaqRKtWdAJPetMRjdAwotYBQcYEIHnSGEgIA11K6f2benF4a4X6eC8gnpi
 thAMteMEc7Nu3kCEgQz+DJUlj1gQqMbsvVzt/fW5lCPZ00whD1kpvvxPVnFTQ+mw
 uQngRaBGY5sNDXV5YZoXS45ltwcLHCX5MbhKWHV1shGCKW0QxNTEQdqEzaJUw/xA
 +9lwCRYbNzzWsHJmx6CS
 =tlId
 -----END PGP SIGNATURE-----
 
 --suMD1gxl821dzEEX--