Date: Sat, 29 Jun 2013 22:00:01 GMT From: Jilles Tjoelker <jilles@stack.nl> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Message-ID: <201306292200.r5TM01p5046315@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: Jilles Tjoelker <jilles@stack.nl> To: bug-followup@FreeBSD.org, Konstantin Belousov <kostikbel@gmail.com>, John Baldwin <jhb@freebsd.org> Cc: guillaume@morinfr.org, theraven@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Sat, 29 Jun 2013 23:53:35 +0200 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! > > > > 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. > > > In other words, we should become knowingly incompatible with the stock > > > 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. > > 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. > libunwind depends on the dl_iterate_phdr() signal-safety. > > 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. > > 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. > I think I should revive the fast sigprocmask patch. 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. 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. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201306292200.r5TM01p5046315>