Date: Mon, 1 Jul 2013 00:30:01 GMT From: Konstantin Belousov <kostikbel@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Message-ID: <201307010030.r610U1Q8035788@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/131597; it has been noted by GNATS.
From: Konstantin Belousov <kostikbel@gmail.com>
To: Jilles Tjoelker <jilles@stack.nl>
Cc: bug-followup@FreeBSD.org, John Baldwin <jhb@freebsd.org>,
guillaume@morinfr.org, theraven@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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307010030.r610U1Q8035788>