On 01/31/2013 03:35 PM, Brian Anderson wrote:
On 01/31/2013 02:37 PM, Patrick Walton wrote:
Hi everyone,
With the revamp of the scheduler underway, I'd like to propose a
change to the way C functions work.
Currently, we generate a shim and a stack switch for every function
call from Rust to C and likewise from C to Rust, except for functions
annotated with `#[rust_stack]`. These wrappers result in a
significant performance overhead. For some workloads this performance
overhead is acceptable in order to maintain small stacks. For some
workloads the performance overhead is undesirable.
For instance, the DOM in Servo requires lots of very small calls from
JavaScript to Rust. The overhead of stack switching swamps most of
the time here. Popular Web benchmarks will do things like
`someElement.clientX;` over and over, which require calls from
JavaScript to Rust to retrieve a cached value. So we must carefully
consider every CPU cycle spent in the C-to-Rust transition.
To address these issues I would like to propose a somewhat radical
change: don't have the compiler generate stack switching stubs at
all. Instead, the scheduler can expose a primitive that generates the
stack switch, and it's the programmer's responsibility to perform the
stack switch to call out to C functions. To avoid the obvious footgun
here, I propose a lint pass, on by default, that ensures that
functions not annotated with `#[rust_stack]` are called inside a
stack switching helper.
The rationale here is as follows:
1. It should be possible to group many C calls under a single stack
switching operation. For example:
do stackswitch {
c_function_1();
c_function_2();
c_function_3();
}
This amortizes the cost of the stack switch over many native function
calls.
I think this API requires #4479 and #4480 to be safe. Currently, the
execution environment after the stack switch is very different, so
running arbitrary Rust code there is dangerous. We may want to think
of 'stack switching' instead as 'make sure I'm running on a stack
segment that is big'. Then whatever code executes after that doesn't
matter - if it's C code it will run till it runs off the stack, if
it's Rust code it will request a new segment when it hits the end.
https://github.com/mozilla/rust/issues/4479
https://github.com/mozilla/rust/issues/4480
An API that was more like `stackswitch!(function, args)` wouldn't have
that problem.
There's also the problem with failure after switching stacks. Right now
there is a guard in the stack switch that catches exceptions thrown by
foreign code and aborts the process, which makes this bogus:
do stackswitch {
fail;
}
We could remove that guard and leave the behavior undefined ...
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
