@nogc and exceptions

[Jakob Ovrum via Digitalmars-d]

On Friday, 12 September 2014 at 21:36:31 UTC, Johannes Pfau wrote:
> I think if we could avoid dynamic allocations for most 
> exceptions
> completely that'd be better. IIRC some people said that 
> exceptions are
> mainly slow because of memory allocation. So if we could avoid 
> that,
> there are more benefits.

While we should ideally make the exception mechanism as fast as 
possible, it mustn't be a priority, lest we compromise more 
important parts of the design for the red herring that is 
performance.

If a program is slow because of exception handling it's not using 
exceptions correctly. It should replace that part of the code 
with a solution that uses error codes. This is the mantra that 
goes for all languages with exceptions that I know, except Python 
and maybe Java.

Also, we know the approximate size of exceptions and their 
allocation pattern. An efficient heap allocator could be designed 
to take advantage of this.

That's not to say I'm against any non-heap solution if we can 
think of something really good, but we should keep our priorities 
straight.

> I suggest looking at the C++ implementation. There's the 
> throw-by-value
> catch-by-reference idiom. C++ must store/copy this exception 
> somewhere,
> maybe they have a clever solution.
>
> (We basically need some fixed-size per thread memory where we 
> can store
> the exception and stack trace info. But we need a fallback 
> because of
> exception chaining or big exceptions.)

I think this is essentially global storage allocation. C++ does 
not do exception chaining so this is much more viable there.

Also, when we decide to use TLS instead of the mess that would be 
shared exceptions, we introduce a massive chunk of required data 
for each new thread in every application that depends on Phobos 
and/or other libraries using the new exception allocator.