DConf talk : Exceptions will disappear in the future?

sighoya sighoya at gmail.com
Thu Jan 7 19:00:15 UTC 2021


On Thursday, 7 January 2021 at 18:12:18 UTC, H. S. Teoh wrote:
> If you're unfamiliar with the subject, I recommend reading a 
> textbook on compiler construction.

I already read one.


> Because every introduced catch block in the libunwind 
> implementation introduces additional overhead.

But only when an exception is thrown, right?

> Wrong. Out of memory only occurs at specific points in the code 
> (i.e., when you call a memory allocation primitive).

What about pushing a new stack frame on top/bottom of the stack? 
This is very implicit. I don't talk about a theoretical Turing 
machine with unbounded memory, rather about a linear bounded 
automaton with finite memory.
What happens if stack memory isn't available anymore?

>> As I said, I don't know how this is handled in D, but in 
>> theory you can even inline an already compiled function though 
>> you need meta information to do that.
>
> This tells me that you do not understand how compiled languages 
> work.

Traditionally, inlining means the insertion of code from the 
callee into the caller, yes.
Imagine now, that the source code of the callee isn't available 
because it is already compiled and wrapped in a dynlib/static lib 
before (and now you link to that dynlib/static lib), then you 
can't inline the source code, but you can inline the binary code 
of the callee. For this to be "optimize-safe" regarding 
exceptions you need to store some meta information, e.g. the line 
number of all direct thrown exceptions in it, during the 
compilation of the callee in the dynlib/static lib for any caller 
outside the dynlib/static lib.
Theoretically, you can even pass functions as binary code blocks 
to the callee, this is mostly inperformant, but it is at least 
possible.

Though, I assume that most compiles doesn't any sort of this, but 
it doesn't mean that it isn't possible.

> Again, I recommend reading a textbook on compiler construction. 
> It will help you understand this issues better. (And it will 
> also indirectly help you write better code, once you understand 
> what exactly the compiler does with it, and what the machine 
> actually does.)

It also depends on the considered compiler and how it is relating 
to the design discussed in textbooks.


> All of this information is already available at compile-time. 
> The compiler can be easily emit code to write this information 
> into some error-handling area that can be looked up by the 
> catch block.

Yes, but the line number is changing when inlining the code, and 
we don't want the new line number to be outputed by the runtime 
if an exception was thrown because it points to a line number 
only visible to the optimizer not to the user?

> Also, you are confusing debugging information with the 
> mechanism of try/catch.

So you only want to output line numbers in stack trace during 
debugging and not in production code?




More information about the Digitalmars-d-learn mailing list