Subject: Re: gcc-dw2? or fast sjlj-exceptions EH
From: Tatsuro MATSUOKA <[email-masked]>
To: "John W. Eaton" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 12 Sep 2007 05:49:05 +0900
List-Id: <cygwin.cygwin.com>

"John W. Eaton" <[email-masked]> wrote:
(2007/09/12 00:24)

| 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.

**********************************
Dear Prof. John W. Eaton
Thank you for your reply.

I cannot entirely understand your reply due to my limited knowledge.
It seems to be difficult to solve the problem by the Danny's 
suggestion.

My question is whether other possibilities to get fast sjlj-exception 
EH in the cygwin.
If there is no way to get the fast sjlj-exception EH, is it possible 
to handle the 'gcc-dw2'?
I know there is 'gcc-dw2' for 4.2.1 version of gcc in the mingw.

However I think the situation on the mingw and that on the cygwin is 
not the same.
In the cygwin, the good install manager that well treats total 
environments are established
but in the mingw there is no such complete system.  

If we would get the development environment, what I have to do is to 
select 'install' in the development category while in the mingw we 
have to install the msys, msysDTK and other tools required.

In the mingw, because the smart system does not exist, it is good 
that there are many selections.
While for the cygwin, the environmental system is totally arranged, 
the parallel existence of the compiler should be treated with the 
great care to avoid the confusion.

I can prepare the package of the 'gcc-dw2' if it will be allowed 
because I have already the gcc with the dwarf2 EH.  However it must 
be done after the discussions on this matter.  I think there will be 
the case that the 'gcc-dw2’ will be rejected to place in the cygwin 
packaging system.  

In that case, my purchase for the fast octave on the cygwin should be 
keep the trail and place the packages within the personal trial.

Thank you again here to Danny and jwe to reply the my comments.

Sincerely yours,

Tatsuro MATSUOKA     

--
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/