On Wed, Jul 12, 2006 at 06:33:09PM +0530, Kamal R. Prasad wrote:
> On 7/12/06, Joerg Sonnenberger <[EMAIL PROTECTED]> wrote:
>
> >On Tue, Jul 11, 2006 at 11:37:52PM +0200, Attilio Rao wrote:
> >> Even if I have no proof-of-concepts (so maybe somebody can show that
> >> this is not fair), if we have setjmp/longjmp in the kernel we can have
> >> a correct exception handling mechanism without not great problems.
> >
> >ROFL. Sorry, but using setjmp/longjmp is one of the worst possible
> >implementation of exceptions since it is very expensive for the hot
> >path, where you don't expect exceptions. They are called "exception" for
> >a reason.
>
>
> so how is exception handling in C++ more efficient than setjmp()/longjmp()
> -in either paths?
The common implementations are based on two assumptions:
- try {} is used often through out the tree and nested
- exceptions are raised seldomly.
This means that the desire to catch an exception should be cheap and the
implementation optimised for that.
What happens is that the compiler creates a table which allows automatic
stack unwinding and matching of the instruction pointers. The former is
necessary to handle frame pointer vs. frame pointer-less stack frames,
the latter is used to determine where an exception should be cought.
Consider:
void bar()
{
throw "foo";
}
void foo()
{
try {
bar();
} catch(...) {
cerr << "error";
}
}
(don't try that, I haven't written C++ for ages)
The compiler creates:
- an entry for the range of bar to annotate that it doesn't have use a
frame pointer
- an entry for foo, with the same annotation
- the address when bar is called in foo (or the address directly
following) to annotate that it should jump to catch, when an exception
is raised.
When an exception is raised, it looks at the current instruction pointer
and begins unwinding the stack until a catch is found. This can be
relatively cheap compared to longjmp, since the register content does
not have to be restored. It does not add any slowdown, as long as
exceptions are not raised.
Joerg
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
