From owner-freebsd-bugs@FreeBSD.ORG Mon Jul 1 00:30:01 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A25AED59 for ; Mon, 1 Jul 2013 00:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 944241183 for ; Mon, 1 Jul 2013 00:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r610U1lu035789 for ; Mon, 1 Jul 2013 00:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r610U1Q8035788; Mon, 1 Jul 2013 00:30:01 GMT (envelope-from gnats) Date: Mon, 1 Jul 2013 00:30:01 GMT Message-Id: <201307010030.r610U1Q8035788@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Konstantin Belousov Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Konstantin Belousov List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 00:30:01 -0000 The following reply was made to PR kern/131597; it has been noted by GNATS. From: Konstantin Belousov To: Jilles Tjoelker Cc: bug-followup@FreeBSD.org, John Baldwin , 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--