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

[Kostik Belousov]

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

From: Kostik Belousov <kostikbel at gmail.com>
To: John Baldwin <jhb at freebsd.org>
Cc: bug-followup at freebsd.org, guillaume at morinfr.org, kan at freebsd.org,
        davidxu at freebsd.org
Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
Date: Fri, 9 Jul 2010 15:56:34 +0300

 --gTY1JhLGodeuSBqf
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Thu, Jul 08, 2010 at 11:29:50AM -0400, John Baldwin wrote:
 > On Friday, April 23, 2010 10:41:11 am Kostik Belousov wrote:
 > > On Fri, Apr 23, 2010 at 10:21:41AM -0400, John Baldwin wrote:
 > > > On Friday 23 April 2010 9:47:40 am Kostik Belousov wrote:
 > > > > On Fri, Apr 23, 2010 at 08:43:41AM -0400, John Baldwin wrote:
 > > > > > On Friday 23 April 2010 8:25:01 am Kostik Belousov wrote:
 > > > > > > On Thu, Apr 22, 2010 at 04:09:34PM -0400, John Baldwin wrote:
 > > > > > > > I tracked the sigprocmask() system calls down to the operatio=
 ns to
 > > > > > > > acquire a write lock in the runtime linker. The lock was adde=
 d to fix
 > > > > > > > an earlier bug with throwing exceptions in multithreaded C++ =
 apps. The
 > > > > > > > relevant commit that added the lock is this:
 > > > > > > >
 > > > > > > >    http://svn.freebsd.org/viewvc/base?view=3Drevision&revisio=
 n=3D178807
 > > > > > > >
 > > > > > > > Are exceptions permitted during a signal handler? If not, the=
 n in
 > > > > > > > theory we would not need to invoke sigprocmask() for this par=
 ticular
 > > > > > > > lock perhaps? I'm not sure how easy that would be to achieve =
 given the
 > > > > > > > hooks to allow the thread library to overload the locking rou=
 tines.
 > > > > > > > Also, this doesn't explain the lack of sigprocmask() calls un=
 der i386.
 > > > > > > > FreeBSD/i386 should be using the same locking code and thus i=
 nvoking
 > > > > > > > sigprocmask() for each exception as well.
 > > > > > >=20
 > > > > > > Throwing an exception during asyncronous signal execution rises=
  undefined
 > > > > > > behaviour, AFAIK. sigprocmask() is there to support libc_r, and=
  cannot
 > > > > > > be removed as far as we need to provide FreeBSD 4.x compatibili=
 ty.
 > > > > >=20
 > > > > > Hmmm.  Why does libthr use sigprocmask() for its rtld locks then?=
   Is that=20
 > > > > > just a copy-paste from libc_r that can be removed now?
 > > > >=20
 > > > > Hmmm^2. It seems it is there to prevent recursive entry into rtld f=
 rom
 > > > > signal handler, that may reference yet unresolved symbol, e.g. libc
 > > > > syscall wrapper, from PLT. So my patch is wrong.
 > > >=20
 > > > Presumably we could use a different type of lock that doesn't use
 > > > sigprocmask() to serialize calls do dl_iterate_phdr()? I'm not sure if
 > > > libthr would really need to overwrite the behavior of that lock or if
 > > > a simple atomic_cmpset()-based mutex would always be fine.
 > > During my porting of libunwind, I was told by libunwind maintainer
 > > that they have to call dl_iterate_phdr() from signal context to
 > > unwind, if libunwind is called from signal context.
 > >=20
 > > Apparently, glibc' dl_iterate_phdr() is not signal-safe, while our is.
 >=20
 > [Revisiting this]
 >=20
 > Do we know of any use cases where libunwind would be used from a signal
 > handler?  Could we instead simply declare it to be an unsafe API in a sig=
 nal
 > context?  longjmp(3) isn't safe in a signal context and throwing exceptio=
 ns
 > in a signal handler is undefined, so declaring libunwind to similarly be
 > unsafe may be fine.
 Yes, one of the typical use of libunwind is profiling, where backtrace
 is done exactly in signal handler. On the other hand, linux is unsafe
 there.
 
 Might be, we should provide some environment variable, that flips the
 safety ?
 >=20
 > > > OTOH, I'm not sure why libthr needs to use non-standard lock hooks at
 > > > this point as they don't seem to be markedly different from the ones
 > > > rtld uses.
 > >=20
 > > libthr locks provide exclusion both for other kernel-executed threads
 > > and signal handlers, while the rtld-default locks only protect against
 > > signal handlers and thus libc_r-style threads.
 >=20
 > Oh, bah.  The rtld locks do use atomic operations that are thread safe,
 > but I missed that the 'oldsigmask' global needs to be per-thread.
 >=20
 > --=20
 > John Baldwin
 
 --gTY1JhLGodeuSBqf
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.10 (FreeBSD)
 
 iEYEARECAAYFAkw3HIIACgkQC3+MBN1Mb4gVJwCdEqUv0VT/dDcIM3NsdieKPWr0
 i6YAoIzUx30immPeo6g/v65nVFaeP3N3
 =YQ3J
 -----END PGP SIGNATURE-----
 
 --gTY1JhLGodeuSBqf--