kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64

[Kostik Belousov]

The following reply was made to PR kern/131597; it has been noted by GNATS.

From: Kostik Belousov <kostikbel at gmail.com>
To: David Xu <davidxu at freebsd.org>
Cc: John Baldwin <jhb at freebsd.org>, bug-followup at freebsd.org,
        guillaume at morinfr.org, kan at freebsd.org
Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
Date: Tue, 14 Sep 2010 14:12:12 +0300

 --S7pq8suDAU0LBjBQ
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Sep 14, 2010 at 02:00:13PM +0000, David Xu wrote:
 > John Baldwin wrote:
 >=20
 > >Do we know of any use cases where libunwind would be used from a signal
 > >handler?  Could we instead simply declare it to be an unsafe API in a=20
 > >signal
 > >context?  longjmp(3) isn't safe in a signal context and throwing excepti=
 ons
 > >in a signal handler is undefined, so declaring libunwind to similarly be
 > >unsafe may be fine.
 > >
 >=20
 > It is true that libunwind would be used from a signal handler.
 > In fact, when I was working on stack unwinding support for libthr, I
 > found it.
 >=20
 > The reason I was trying to do it is that I want to let C++'s on-stack
 > object to be destructed when thread is exited, otherwise, C++ program
 > can not use pthread cancellation feature, the pthread cancellation
 > calls pthread_exit(), and the function should unwind the thread's stack
 > for C++ like language, otherwise the programs leak resource.
 >=20
 > In head branch, things are improved, for defer-mod, thread cancellation
 > is called from in-place context, but for asynchronous mode, thread
 > cancellation is called from a signal handler, the SIGCANCEL hanlder, so
 > the libunwind needs to dig out the saved context and unwind the
 > interrupted stack.
 >=20
 > A very bad news is libunwind only did unwind-through-signal-stack for
 > linux, nothing has been done for FreeBSD and others, code has been
 > found here:
 > /usr/src/contrib/gcc/config/i386/linux-unwind.h
 Err ? When I ported libunwind, I spent a lot of time making unwind
 through the signal frame working. The part of the trouble was that
 our signal trampoline lacks unwind info. And annotating the trampoline
 is not a whole solution, since libunwind can only find the FDEs by
 =2Eeh_frame_hdr of some dso. This would require creating fake dso for
 trampolines.
 
 I decided to use old-linuxish method of unwinding by hardcoding frame
 format and trampoline code sequence for detection.
 
 >=20
 > I even have a patch for FreeBSD x86 to support the
 > unwind-through-signal-stack, but I have not fully tested it.
 > http://people.freebsd.org/~davidxu/patch/unwind.patch
 > You can say this is a crazy idea, but they did it.
 >=20
 > >>>OTOH, I'm not sure why libthr needs to use non-standard lock hooks at
 > >>>this point as they don't seem to be markedly different from the ones
 > >>>rtld uses.
 > >>libthr locks provide exclusion both for other kernel-executed threads
 > >>and signal handlers, while the rtld-default locks only protect against
 > >>signal handlers and thus libc_r-style threads.
 > >
 > >Oh, bah.  The rtld locks do use atomic operations that are thread safe,
 > >but I missed that the 'oldsigmask' global needs to be per-thread.
 > >
 >=20
 > In head branch, when program is linked with libthr, and created a
 > thread, the libthr's rtld lock implementation is activated,
 > performance should be improved, but otherwise, it is still slow for
 > non-threaded C++ program.
 
 BTW, the signal handler interposition that you implemented for libthr
 probably belongs to libc. I already implemented dso filtering for
 our rtld, so I hope to start discussion about merging libc and libthr
 into single library. Then libc could interpose signal handlers.
 
 --S7pq8suDAU0LBjBQ
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.10 (FreeBSD)
 
 iEYEARECAAYFAkyPWIsACgkQC3+MBN1Mb4jN7wCg0DrtBTWEhOzMQNr9+nTYnYFu
 l7kAoIBzrW8xguotia3aSj45Hr/2G4Kb
 =r1Ml
 -----END PGP SIGNATURE-----
 
 --S7pq8suDAU0LBjBQ--