Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Jun 2013 21:30: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:  <201306302130.r5ULU15s092547@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: Konstantin Belousov <kostikbel@gmail.com>
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: Sun, 30 Jun 2013 23:28:55 +0200

 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.
 
 OK :(
 
 > > 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.
 
 > 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.
 
 > 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.
 
 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.)
 
 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.
 
 An example of this partial merge is lib/libc/gen/sem_new.c.
 
 -- 
 Jilles Tjoelker



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201306302130.r5ULU15s092547>