X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Tue, 11 Sep 2007 11:24:11 -0400
From: "John W. Eaton" <jwe AT bevo DOT che DOT wisc DOT edu>
Subject: RE: gcc-dw2? or fast sjlj-exceptions EH
In-reply-to: <000001c7f3f6$e64897d0$276d65da@THOMAS>
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>
Message-id: <18150.45851.316538.375920@segfault.lan>
MIME-version: 1.0
X-Mailer: VM 7.19 under Emacs 22.1.1
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Spam-Report: AuthenticatedSender=yes, SenderIP=75.187.161.108
X-Spam-PmxInfo: Server=avs-12, Version=5.3.3.310218,  Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.9.11.80726,  SenderIP=75.187.161.108
References: <000001c7f3f6$e64897d0$276d65da AT THOMAS>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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.

jwe

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/