From owner-freebsd-bugs@FreeBSD.ORG Tue Sep 14 06:10:04 2010 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ECE3106566C for ; Tue, 14 Sep 2010 06:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F24BC8FC13 for ; Tue, 14 Sep 2010 06:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8E6A3Nt089359 for ; Tue, 14 Sep 2010 06:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8E6A3F6089346; Tue, 14 Sep 2010 06:10:03 GMT (envelope-from gnats) Date: Tue, 14 Sep 2010 06:10:03 GMT Message-Id: <201009140610.o8E6A3F6089346@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: David Xu Cc: 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.5 Precedence: list Reply-To: David Xu List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 06:10:04 -0000 The following reply was made to PR kern/131597; it has been noted by GNATS. From: David Xu To: John Baldwin Cc: Kostik Belousov , bug-followup@freebsd.org, guillaume@morinfr.org, kan@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.