Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing Faster Exceptions to Rust

purplesyringa.moe

Post reply on HN
Print view View original

11–20 of 35 posts

Re: Bringing Faster Exceptions to Rust

#11

Post by gpderetta »

tsimionescu wrote: post #4
codeflo wrote: post #3

> Returning to an alternate address shouldn’t be significantly more expensive than returning to the default address, so this has to be cheap. Modern CPUs add complications to arguments like this. Branches stall the execution pipeline, so branch prediction was invented to keep the pipeline flowing. Return instructions are perfectly predicted, which makes them literally free. At the very least, any alternate return sch…

This doesn't really make sense. The branch predictor relies on a history of previous executions of that branch, or on explicit hints, to decide if a branch will be taken or not. Based on this prediction, the speculative execution hardware then sees the jump (return/panic) and loads the code from that address into the icache. There is 0 difference between `if (condition) jump $panic_recover_address` and `if (condition…

returns, conditional jumps and indirect jumps have each fairly different prediction profiles. In particular paired call+ret are predicted perfectly at least until the dedicated internal stack doesn't overflow; indirect jumps are, as a general rule, less predictable than conditional jumps as more state (the jump target) need to stored.

Re: Bringing Faster Exceptions to Rust

#12

Post by gpderetta »

Joker_vD wrote: post #9
codeflo wrote: post #5

Earlier quoted context omitted.

On x86, ret and call are explicit instructions. Ret always predicts the address of the last call, which is (usually) 100% accurate. Your example of `if (condition) jump $panic_recover_address` contains two branches, either of which can be mispredicted.

Sine Intel processors have shadow (call-)stack to ensure control-flow integrity, I imagine they use it to predict the return address as well.

Intel (and most CPUs really) have had a "shadow" call stack for ret+call prediction (the Return Stack Buffer) decades before they had the control-flow integrity shadow stack. It is possible that the two stacks are now unified, but I'm not 100% sure.

The RSB has 10 or so entries and it is in the critical path, while the integrity stack might be larger and have less strict performance characteristics, so they might be separate objects.

Re: Bringing Faster Exceptions to Rust

#13

Post by Yoric »

Joker_vD wrote: post #10

Well, unwinding can be as simple (and as fast) as MOV SP, [installed_handler] JMP [installed_handler+WORD] but it only works if you don't need to run the defers/Drop's/destructors/etc. for stuff that's on the stack between the current frame and the handler's frame. Which you do, most of the time.

Also, I don't think it's possible to perform any kind of backwards-compatible static analysis that would tell you when it's safe to just JMP. Unless you have full information, perhaps (at the very least everything already specialized).

Re: Bringing Faster Exceptions to Rust

#14

Post by gpderetta »

Joker_vD wrote: post #10

Well, unwinding can be as simple (and as fast) as MOV SP, [installed_handler] JMP [installed_handler+WORD] but it only works if you don't need to run the defers/Drop's/destructors/etc. for stuff that's on the stack between the current frame and the handler's frame. Which you do, most of the time.

> it only works if you don't need to run the defers/Drop's/destructors/etc

Indeed. And the per frame cleanup is also language agnostic which adds overhead; it also must support both sjlj and dwarf frames[1]; it is also done in two phases: destructors are only run if an actual catch is found: an unhandled exception doesn't run destructors to preserve state in the core file. This requires a two-phase unwinding that again slows things down.

Another big bottleneck that might not be captured in OP test is that the unwinder has to take (or used to, things got better recently) a global lock to prevent races with dlclose, which greatly limit scalability of exception handling.

Still very nice improvements from OP.

[1] although I'm not sure you can mix them in the same program or it is a platform-wide decision.

Re: Bringing Faster Exceptions to Rust

#15

Post by tsimionescu »

codeflo wrote: post #7
tsimionescu wrote: post #6

Earlier quoted context omitted.

No, an unconditional jump to a fixed address can't be mispredicted.

How can a reusable function have a fixed return address?

This is a good point that I hadn't considered - these are indirect jumps, and the return instruction has special handling from the processor to compute the address specifically, which a jump to a recover address can't have.

Re: Bringing Faster Exceptions to Rust

#16

Post by meindnoch »

codeflo wrote: post #3

> Returning to an alternate address shouldn’t be significantly more expensive than returning to the default address, so this has to be cheap. Modern CPUs add complications to arguments like this. Branches stall the execution pipeline, so branch prediction was invented to keep the pipeline flowing. Return instructions are perfectly predicted, which makes them literally free. At the very least, any alternate return sch…

>Return instructions are perfectly predicted

As long as you don't overwrite the return address on the stack.

Re: Bringing Faster Exceptions to Rust

#17

Post by bjackman »

tsimionescu wrote: post #6
codeflo wrote: post #5

Earlier quoted context omitted.

On x86, ret and call are explicit instructions. Ret always predicts the address of the last call, which is (usually) 100% accurate. Your example of `if (condition) jump $panic_recover_address` contains two branches, either of which can be mispredicted.

No, an unconditional jump to a fixed address can't be mispredicted.

Yes it can, prediction begins before decode. In general, literally any instruction can be mispredicted, even if it isn't a branch at all, even if there isn't even a instruction there (on x86 where instructions are variable length).

Re: Bringing Faster Exceptions to Rust

#18

Post by Joker_vD »

gpderetta wrote: post #14
Joker_vD wrote: post #10

Well, unwinding can be as simple (and as fast) as MOV SP, [installed_handler] JMP [installed_handler+WORD] but it only works if you don't need to run the defers/Drop's/destructors/etc. for stuff that's on the stack between the current frame and the handler's frame. Which you do, most of the time.

> it only works if you don't need to run the defers/Drop's/destructors/etc Indeed. And the per frame cleanup is also language agnostic which adds overhead; it also must support both sjlj and dwarf frames[1]; it is also done in two phases: destructors are only run if an actual catch is found: an unhandled exception doesn't run destructors to preserve state in the core file. This requires a two-phase unwinding that aga…

> the unwinder has to take (or used to, things got better recently) a global lock to prevent races with dlclose

If someone from another thread decided to unload a library whose code is still being executed in this thread then this thread would normally crash anyhow, and do so irrecoverably, right?

Re: Bringing Faster Exceptions to Rust

#19

Post by jnordwick »

tsimionescu wrote: post #4
codeflo wrote: post #3

> Returning to an alternate address shouldn’t be significantly more expensive than returning to the default address, so this has to be cheap. Modern CPUs add complications to arguments like this. Branches stall the execution pipeline, so branch prediction was invented to keep the pipeline flowing. Return instructions are perfectly predicted, which makes them literally free. At the very least, any alternate return sch…

This doesn't really make sense. The branch predictor relies on a history of previous executions of that branch, or on explicit hints, to decide if a branch will be taken or not. Based on this prediction, the speculative execution hardware then sees the jump (return/panic) and loads the code from that address into the icache. There is 0 difference between `if (condition) jump $panic_recover_address` and `if (condition…

I thought the Branch Target Predictor on x64 was global, not local, and it has to kick in before decode so even direct branches can be mispredicted. Branch prediction is 2 parts - the conditional predictor and the target predictor. The conditional predictor is actually per 64 byte instruction block (so if you have a few branches consecutively they share branch predictor entries and can step on each other. the target predictor uses a global history and needs to happen very early to keep the front end fed.

Re: Bringing Faster Exceptions to Rust

#20

Post by gpderetta »

Joker_vD wrote: post #18
gpderetta wrote: post #14

Earlier quoted context omitted.

> it only works if you don't need to run the defers/Drop's/destructors/etc Indeed. And the per frame cleanup is also language agnostic which adds overhead; it also must support both sjlj and dwarf frames[1]; it is also done in two phases: destructors are only run if an actual catch is found: an unhandled exception doesn't run destructors to preserve state in the core file. This requires a two-phase unwinding that aga…

> the unwinder has to take (or used to, things got better recently) a global lock to prevent races with dlclose If someone from another thread decided to unload a library whose code is still being executed in this thread then this thread would normally crash anyhow, and do so irrecoverably, right?

well yes, but I think the mutex also protects some other global datastructures.

I think the mutex was mostly removed recently, by observing exactly what you mention: any race would be UB anyway.

Post reply on HN