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: Mon, 1 Jul 2013 03:24:06 +0300

 --tdVUlQTxnujgnAno
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Sun, Jun 30, 2013 at 11:28:55PM +0200, Jilles Tjoelker wrote:
 > On Sun, Jun 30, 2013 at 06:12:32AM +0300, Konstantin Belousov wrote:
 > > 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:
 > > As I said, libunwind relies on the signal blocking behaviour to be able
 > > to unwind from the signal handler.
 >=20
 > OK :(
 >=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.
 >=20
 > > 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.
 >=20
 > > 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.
 >=20
 > A full merge would make people unhappy who want a separate unthreaded
 > programming environment so that, for example, libstdc++ can allocate
 > smaller data structures without locks. (Note that this requires breaking
 > pthread_once() in the unthreaded programming environment.)
 libgcc++ could switch to the method used by all other platforms, on
 the FreeBSD too.  It seems that the presence of the pthread_cancel()
 symbol works as an indicator.  We can easily implement the switch
 locally, and I am sure that upstream will accept such change.
 
 >=20
 > However, even without pthread_create() and pthread_once(), a lot of
 > functionality could be moved from libthr to libc, assuming we are
 > willing to declare mixing and matching libc and libthr versions
 > completely unsupported (by adding a check). For example, the signal
 > handling, cancellation checks and errno. In the case of dynamic linking,
 > a partial merge will require fewer symbols to be exported
 > FBSDprivate_1.0 which reduces PLT indirection and will make up for some
 > overhead.
 We already do not support mixing different versions of libc and libthr,
 since libthr copies the pthread stubs over the libc table.
 
 >=20
 > An example of this partial merge is lib/libc/gen/sem_new.c.
 
 In fact, the export of the pthread* symbols from libc is very unfortunate.
 
 --tdVUlQTxnujgnAno
 Content-Type: application/pgp-signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.20 (FreeBSD)
 
 iQIcBAEBAgAGBQJR0MwlAAoJEJDCuSvBvK1BSkwP+wa9pn0DcrxOlt16Kl5bARph
 +yQriobX54RilXMBEuhB07IFxN+iECGgbXieq3iPMhY5Q925doZIjIKViFfnPWfy
 MD4dpQKxpVInL77/GOPeBzGcqNtMg/Ubfn4pKAP9Mmv+mNIjPOVOka8zzDwTCyrR
 NkNMyA4bNtUWVnb6y1yb1t2PUP3W9RTjhbC9xgfCwXzL1IwwWZwMv0+Ate75E5EY
 I7F+eOUqhCWNHUHfw4ezF7ZqB7faY9/ScGJTKbOlJ8C9h0BtnNeb/zCZXsgu4+UN
 Gt6LtpQib5eya05braKOJVaALpksQ+MHTNvWmMmodBLnjHu4fyVfBTmAwNkk+VnQ
 UaXMpGsiuGev4ebfF3ccVDVYgsUXM4mZM+RmyBoMKJ64fNtXO+esBNSBqAPH2GzK
 WE426lq+MPXj4kG5WXGiW7oDY4L1jYM8yEH+E5NL1MdEXZmDiKvPvRQjEfnaB8HJ
 9XgJCKEDSPuxD1lkmLhLzEke0SCN+r+CoDbbyL5MSPzCSQjeYxCy27iO7yg/G/65
 +wzPwLTtR2V/ujuDcYUVXCDff/Uqcs44rlcfQ9fzpOyWa0Z2bZ+7zyVs4xhwhW4Y
 Y8tV+yLXRjwPMyoUv+ODDbEZlUpob2Kj9wiVqB/9r4lwunDpDUzTq1v2+JNl9jTr
 R1ZGkOAUMKWZzxhaJqgj
 =N7Lu
 -----END PGP SIGNATURE-----
 
 --tdVUlQTxnujgnAno--