While the code paths may be marginally faster, exception handling in
this time efficient way has a huge overhead: the code and tables are
about twice as large.
For a demand-paged application this is not a problem, but for the
non-pageable kernel, a doubling in the memory footprint is totally
unacceptable.
The code paths are not always faster, anyway. The extra edges in the
flow graph suppress some optimisations (specifically, to do with
reordering and retaining values on the stack). These extra edges are
often present in the C style as well, but not always and less often
because they are not implied by every hidden constructor call etc.
And the error checking mechanisms in the kernel are very efficient.
Most cases compile to `movl $-EXXX,%ebx; /* call */; testl %eax,%eax; jn
.Lout'. The memory fault handlers are very tidy.
Finally, exceptions are designed to be fast in the non-exceptional case,
at the cost of very slow in the exceptional case. In the kernel, very
many error conditions are expected to occur often. So it would be
inappropriate to use exception handlers for trapping errors.
BTW, one efficiency trick that EGCS exceptions provide, namely moving
the unexpected case out of line, has actually being considered as a C
extension recently.
> I agree that C++ modules should be supported, but they will need to be
> compiled "-fno-exceptions". The only real work needed to enable it is
> some cleanup in the headers. I estimate about a month full-time, or less.
> If each of two dozen people spent a day on it, it would be done.
Compiling C++ modules works just fine in most cases. Be careful with
your stack usage.
Some headers are a problem, but frankly, they are a problem with some C
applications too because of Glibc/Linux conflicts.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/