Proposal: Exceptions and @nogc
Walter Bright via Digitalmars-d
digitalmars-d at puremagic.com
Sun Apr 2 13:35:27 PDT 2017
On 4/2/2017 8:24 AM, Dmitry Olshansky wrote:
> Copy means allocate and then deallocate in the catch, defeating the whole
> propose of preallocating.
That's right.
> Would it be possible to just set a bit somewhere that
> indicates that the exception is preallocated and need not be freed.
Yes, it's possible. But I'd have to be convinced that there isn't some other
problem with a design that requires preallocated exceptions.
Exceptions are slow; they are designed to totally favor the non-throwing path.
Walking the stack and looking through the tables looking for the right stack
frame information is slow. Unwinding is slow. The druntime exception handling
code is dog slow (it's just as agonizing in C++, it's not a D thang).
If the D exception allocator uses a pool, and exceptions are held to being just
a few bytes long (they can always use PIMPL if they have large data
requirements), they'll be very cheap to allocate and initialize. It's hard to
see how that would be a problem, given the rest of what goes on in
throwing/unwinding.
I can see preallocated exceptions needed for avoiding GC and hence an adversely
timed GC pause/collect cycle. But with this proposal, I can't see the value.
More information about the Digitalmars-d
mailing list