New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run Rust code on native stack segments #4479

Closed
brson opened this Issue Jan 14, 2013 · 7 comments

Comments

Projects
None yet
6 participants
@brson
Contributor

brson commented Jan 14, 2013

Currently when we call into C code we don't update the stack pointer to account for the native stack segment, and when we call back into Rust code we immediately switch back to a Rust stack, wasting space on the native stack.

Instead, we should treat the foreign segment the same as any other - putting it into the TCB. Instead of an explicit stack switch to call Rust code, we'll just Run it on the foreign stack. Then the Rust code will start adding new stack segments as needed.

This will give uv callbacks better performance, and will eliminate some of performance concerns around calls from SpiderMonkey into the Rust DOM.

It will also eliminate the need to set the TCB stack pointer to 0 when entering the native stack, eliminating some of the need for no_split_stack. (#1804, #1226)

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jan 14, 2013

Contributor

This may necessitate changes in how we manage multiple reentries into the foreign stack, but I don't remember exactly what we do now.

Contributor

brson commented Jan 14, 2013

This may necessitate changes in how we manage multiple reentries into the foreign stack, but I don't remember exactly what we do now.

@graydon

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon Apr 30, 2013

Contributor

@pcwalton is this in-scope or related to what you're doing in 0.7?

Contributor

graydon commented Apr 30, 2013

@pcwalton is this in-scope or related to what you're doing in 0.7?

@graydon

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon Apr 30, 2013

Contributor

assigning bug; change assignment if you disagree

Contributor

graydon commented Apr 30, 2013

assigning bug; change assignment if you disagree

@ghost ghost assigned pcwalton Apr 30, 2013

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Jul 2, 2013

Member

@pcwalton should we drop this from the 0.7 milestone?

Member

pnkfelix commented Jul 2, 2013

@pcwalton should we drop this from the 0.7 milestone?

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jul 3, 2013

Contributor

Bumping from 0.7

Contributor

brson commented Jul 3, 2013

Bumping from 0.7

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Sep 8, 2013

Member

Nominating for a milestone. I'm not entirely sure how this interacts with the current runtime along with all the FFI changes for extern fns that happened recently. I would suggest milestone 1 because this sounds like it will likely help define how we manage stacks during FFI, but I would also be OK with other milestones.

Member

alexcrichton commented Sep 8, 2013

Nominating for a milestone. I'm not entirely sure how this interacts with the current runtime along with all the FFI changes for extern fns that happened recently. I would suggest milestone 1 because this sounds like it will likely help define how we manage stacks during FFI, but I would also be OK with other milestones.

@catamorphism

This comment has been minimized.

Show comment
Hide comment
@catamorphism

catamorphism Sep 12, 2013

Contributor

Closing as obsolete

Contributor

catamorphism commented Sep 12, 2013

Closing as obsolete

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment