Catching panics is eating into Servo's DOM performance

[jdm]

I have a profile showing that of 60% of execution time spent under a Rust callback from SpiderMonkey that corresponds to invoking a method on a JS object inside of a hot loop, fully half of that time is spent inside __rust_try, __rust_maybe_catch_panic, and std::panicking::PANIC_COUNT::__getit. Since we go Rust -> C++ -> JS -> C++ -> Rust when executing JS that invokes a DOM method, every loop iteration we call catch_unwind in the Rust callbacks invoked by C. This appears to be impacting our potential maximum performance significantly.

Issues to solve

• Use only one personality function - Use only one personality function instead of 2 on Unix #34786
• Inline cross-crate thread-local access - Access to thread locals isn't inlined across crates #25088
• Don't hit TLS when entering catch_unwind - Don't hit thread-local-storage when entering catch_unwind #34787

[eefriedman]

I assume you mean that std::panic::catch_unwind is slow, even if the called code doesn't panic? That's bad. Probably code which should be inlined isn't getting inlined for some reason.

CC @alexcrichton

[jdm]

Yes, that's correct.

[alexcrichton]

Unfortunately there's not a lot we can do here to easily make this better. The catch_unwind function was not prioritized to be fast as it was assumed it's only crossed at isolation boundaries, which should be relatively rare in theory.

That's not to say it can never be fast, just that it's going to be difficult. The reasons you're seeing this today are:

• Thread locals across crates are not easily inlined
• With the design of panic runtimes, the call to __rust_maybe_catch_panic is unconditional and will never go away unless you LTO. This prevents some inlining.
• The __rust_try function is generated by the compiler specially because it has a different personality function than all the rest of the Rust code in the world. As a result, LLVM cannot inline this because there are differing personality functions.

There are a few local optimizations possible, such as not using options here, but I've tried that out locally and it doesn't really buy you much.

LTO will buy you the most in terms of optimizations because thread local access can get inlined as well as __rust_maybe_catch_panic. At that point all that can't be inlined is __rust_try. We could try to finagle only using one personality routine so this could get inlined, but it may not be trivial.

That's at least my current thoughts for now, unfortunately that may not help much, but hopefully it's at least a little illuminating!

[alexcrichton]

Some ideas for how to get rid of TLS:

We don't actually need to hit TLS when we run catch_unwind, the only thing it's doing is resetting the panic counter to 0. This is if you have something like this:

use std::panic::catch_unwind;
struct A;

let _a = A;
panic!();

impl Drop for A {
    fn drop(&mut self) {
        catch_unwind(|| panic!());
    }
}

That program doesn't abort. Now whether or not that program aborts with a double panic seems a bit iffy to me. This means that a catch_unwind changes thread::panicking to false which is arguably the wrong thing to do because the thread is still panicking. I'd be fine saying that something like this is akin to double panic, but others may feel differently.

Basically, what I'm getting at is that we could try to remove the hit to TLS in catch_unwind if possible. All we need to do then is to be able to detect when panicking if we're already panicking. This may be possible with some sort of stack unwinding (maybe throw a "pseudo-exception" to see if something catches it?) or something like that. Haven't thought this through all the way, but it should be fine for us to make panics basically as arbitrarily slow as we can.

Next, to enable all the inlining we need to get rid of our two personality functions and only have one. This should be possible as C++ does it all the time. The implementation of our personality function would then have to inspect the "language specific data area" I believe (the LSDA) and basically see if the function the personality is running for contains a catch. I believe this is encoded in DWARF somewhere and we just need to read it out, I do not understand the specifics of doing so however.

If we can get both of those done then we the only point where we can't inline is the __rust_maybe_catch_panic boundary, which seems fine as LTO easily erases it.

[arielb1]

Can't you compile servo with -C panic=abort?

[jdm]

That would remove a significant reason for Servo to be written in Rust; thread isolation from panics is one of our selling points.

[alexcrichton]

I've updated the description of this issue to list the primary issues to solve to close out this issue. I figure we can leave this open though for discussion about perhaps different strategies for optimization.