Date: Thu, 13 Jul 2006 11:16:18 +0530 From: "Kamal R. Prasad" <kamalp@acm.org> To: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ Message-ID: <ac7deb50607122246k7df45813hf9cb34e1f8269c77@mail.gmail.com> In-Reply-To: <20060712132059.GA3906@britannica.bec.de> References: <courier.44B35DBC.00003F75@intron.ac> <courier.44B37714.00004B4D@intron.ac> <868xn0z8w9.fsf@xps.des.no> <courier.44B3B9A0.0000609C@intron.ac> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> <3bbf2fe10607111437h6547432fn2887348708df29a4@mail.gmail.com> <20060712113516.GC2162@britannica.bec.de> <ac7deb50607120603t6607ff97j4f5cf1749b6e426b@mail.gmail.com> <20060712132059.GA3906@britannica.bec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Im sorry I didn't understand you. setjmp() stores a few register contents
[notably ip] in a jmpbuf -which are restored after a longjmp(). How is the
try/catch mechanism more efficient than a setjmp()/longjmp() in terms of
space/time complexity?
thanks
-kamal
On 7/12/06, Joerg Sonnenberger <joerg@britannica.bec.de> wrote:
>
> On Wed, Jul 12, 2006 at 06:33:09PM +0530, Kamal R. Prasad wrote:
> > On 7/12/06, Joerg Sonnenberger <joerg@britannica.bec.de> 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 "freebsd-hackers-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ac7deb50607122246k7df45813hf9cb34e1f8269c77>