This is the mail archive of the
mailing list for the Cygwin project.
RE: gcc-dw2? or fast sjlj-exceptions EH
- From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
- To: Danny Smith <dannysmith at clear dot net dot nz>
- Cc: matsuoka at nuce dot nagoya-u dot ac dot jp, Cygwin <cygwin at cygwin dot com>
- Date: Tue, 11 Sep 2007 11:24:11 -0400
- Subject: RE: gcc-dw2? or fast sjlj-exceptions EH
- References: <000001c7f3f6$e64897d0$276d65da@THOMAS>
On 11-Sep-2007, Danny Smith wrote:
| At http://www.cygwin.com/ml/cygwin/2007-09/msg00194.html
| Tatsuro Matsuoka wrote:
| > The best solution, I think, the speed of sjlj-exceptions EH on the
| > cygwin is as fast as that of other platforms.
| In the case of octave, I believe that the main cause of slowdown is the
| sjlj EH code generated in prologue of new()
| Does a no-throw override of libary version of these functions help ?
Octave does not set up a new handler because it expects that a failed
allocation will throw a std::bad_alloc exception. Given that, it
seems that the replacement for operator new that you posted would
cause Octave to crash on a failed allocation, and that's not an
acceptable solution for an interactive system like Octave.
If we did install a new handler, could it throw a std::bad_alloc
exception and still avoid the performance problem? I don't see how,
as it seems that would just be pushing the problem one function call
level deeper but without any real change in the way things work.
It's also not acceptable to install a new handler that doesn't throw
an exception but just does a longjmp because then all the nice cleanup
things that are supposed to happen with exception handling are
bypassed when recovering from the failed allocation.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html