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?
