On Tuesday 25 April 2006 11:06, Matt Keenan wrote:
> Avi Kivity wrote:
> >
> > Maybe not mathematically, but I can try to hand-wave my way through.
> >
> > By using exceptions, you free the normal return paths from having to
> > check for errors. The exception paths can be kept in a dedicated
> > section, avoiding cache pollution. The total code (and data) size
> > increases, but the non-exception paths size decreases significantly
> > and becomes faster.
> >
> > Using C++ objects instead of C objects allows you to avoid void
> > pointers, which are difficult for the compiler to optimize due to
> > aliasing.
>
> Exception handling on a kernel with a 4K stack would be very
> interesting, now imagine what would happen if one exception triggered
> another? and possibly another?? And even giving up on the stack issues,
> what about cacheline / performance issues? Moving error handling even
> further from the fast path isn't going to help performance much.. How
> about an exception for every ENOENT? Have you seen how many ENOENT's
> /lib/ld-linux.so.2 generates when a large app starts? Take firefox, load
> it, let it open five tabs, then shut it down. On my system, 1377
> open()'s, 527 of which are ENOENT, 135 of those before the program has
> finished linking. Not exactly the best way to speed the system up. And
> don't say you can use the dentry cache to return an object or NULL, as
> this is just replication of what C does, but with even more syntatic
> goop. C++ is a good tool, for the right job. The kernel is not one of them.
>
To enable stack unwinding for exception handling, extra exception-related
information about each function needs to be available for each stack frame.
This information describes which destructors need to be called (so that local
objects can be cleaned up), indicates whether the current function has a try
block, and lists which exceptions the associated catch clauses can handle.
Take a look at a typical OOPS trace and tell me if that will fit in a 4k stack
with C++ and stack unwinding.
---
Choose the right tools, use them the right way.
Refuse to compromise, expect to succeed,
Then start again.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]