Re: How expensive are exceptions?
on Sat Jun 16 2007, Sebastian Redl <e0226430-AT-stud3.tuwien.ac.at> wrote:
On Sat, 16 Jun 2007, Walter Bright wrote:
Right, but it's nice being compatible with the standard way the
operating system works. For example, if a hardware exception occurs, you
get an SEH which can be caught by C++.
Yes, but as I recall, this "feature" of VC++6 was attacked fiercely and
removed from VC++.Net 2002. So it was apparently not found to be so nice
after all.
Yes, more about the reasons why here:
http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/2d5c923a8f6bf710
As for cross-DLL exception throwing, that's an illusion
anyway. Pretty much every C++ compiler has its own ABI, at least far
enough that code from two compilers cannot interact on the C++
level, having instead to rely on C APIs. Exceptions are one reason
for this incompatibility, but not the only one. RTTI information
layout is another.
Looking at it another way, SEH is Microsoft's standard ABI for
exceptions on 32-bit windows. I don't have a problem with that (other
than that it's dog-slow and hardware exceptions are tied into it).
But if two modules cannot interact in C++ terms anyway, there's
hardly a point in making their exception handling mechanisms
compatible, is there? If two compilers really want to interact,
they can synchronize their methods. Hopefully they'll agree on good
methods.
Unfortunately in this case, MS got to define the platform standard
long ago when nobody knew better ;-)
For a generational GC, you can avoid scanning sections of memory that
you know haven't changed since the last time it was scanned. This is
done by implementing a "write barrier", which marks the section as
"changed and needs rescanning" when it is written to. One way to do this
is to instrument every write instruction. Another way is to mark those
sections' pages as "read only". Then, the hardware throws a "write
fault" exception when an instruction tries to write to it. You set up a
handler that intercepts the write fault, logs the faulting page as
"changed and need rescanning", then turns on the write enable bit for
the page, and restarts the instruction.
This is not practical if the exception unwinding is slow.
It is my understanding that this mechanism relies on restart semantics,
which are not supported by C++ anyway. Furthermore, restart semantics do
not lead to stack unwinding. (If the stack is unwound, how could the
function resume running?) Only the lookup of an exception handler is
needed.
Exactly.
Thus, you could, for example, split the range table in two parts: one
containing basic information (where the exception handlers are, where to
find the return address) and one containing the advanced information (how
to unwind each stack frame).
The first table should be quite small and can thus be held in memory and
be fast to access. Since this is all that is needed for restart semantics,
the write protection trick should work.
I don't even think you need your EH tables for that purpose. IIUC
it's just standard hardware exception handling, done the same way that
page faults are handled.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]