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

[David Xu]

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

From: David Xu <davidxu at freebsd.org>
To: John Baldwin <jhb at freebsd.org>
Cc: Kostik Belousov <kostikbel at gmail.com>, 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:00:13 +0000

 John Baldwin wrote:
 
 > 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 signal
 > context?  longjmp(3) isn't safe in a signal context and throwing exceptions
 > in a signal handler is undefined, so declaring libunwind to similarly be
 > unsafe may be fine.
 > 
 
 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.
 
 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.
 
 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.
 
 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
 
 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.
 
 >>> 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.
 > 
 
 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.