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

Some work on freestanding Rust: foreign calls, exchange allocator #4619

Merged
merged 3 commits into from Feb 7, 2013

Conversation

Projects
None yet
2 participants
@brson
Contributor

brson commented Jan 25, 2013

r? @graydon

This is some initial work on freestanding Rust I've had sitting around. It is needed to write scheduler code in Rust.

It does two major things:

  1. Calls to upcall_call_on_c_stack/upcall_call_on_rust_stack will first check whether they are running in 'task context', i.e. if they can find the task pointer. If not they will call the function directly without switching stacks. This allows the same foreign function declarations to work either with or without the runtime.
  2. It rewrites the exchange allocator so that it works outside of task context so that any Rust code can allocate owned types.

My intent was to write the exchange heap allocator in Rust but after I did so I noticed that there are still a number of C++ utility functions that make exchange heap allocations. As a result there is one written in Rust and one written in C++ (that both just use malloc), and they share a global atomic reference count of allocations. This change loses some of the debugging facilities provided by the existing memory_region allocator. It may be that this iteration of the allocator is insufficient, but I'd like your opinion.

@graydon

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon Jan 27, 2013

Contributor

r+ overall, I trust you have a plan here. I'm confused about a number of elements and left a few line comments but don't let me slow you down. I'm fine with the multiplication of wonky allocators as stopgap measures; we're going to have a much more serious allocator -- or set of allocators -- at some point this year, this is all transitional.

For my own understanding: I realize bug #4457 uses the term "without a runtime", but to be precise: "without a runtime" is used here as an exact synonym for "running in a thread that hasn't put a task pointer in TLS", correct? There are enough moving pieces here that I think it pays to be precise in what we're talking about / doing.

(The potential additional state of "has a task pointer in TLS but it's not accurate due to someone switching stacks without updating TLS" is ... one of the reasons I'd like to move to pulling the task pointer out of (sp & ~0xfff) + 0x1000 or such)

Contributor

graydon commented Jan 27, 2013

r+ overall, I trust you have a plan here. I'm confused about a number of elements and left a few line comments but don't let me slow you down. I'm fine with the multiplication of wonky allocators as stopgap measures; we're going to have a much more serious allocator -- or set of allocators -- at some point this year, this is all transitional.

For my own understanding: I realize bug #4457 uses the term "without a runtime", but to be precise: "without a runtime" is used here as an exact synonym for "running in a thread that hasn't put a task pointer in TLS", correct? There are enough moving pieces here that I think it pays to be precise in what we're talking about / doing.

(The potential additional state of "has a task pointer in TLS but it's not accurate due to someone switching stacks without updating TLS" is ... one of the reasons I'd like to move to pulling the task pointer out of (sp & ~0xfff) + 0x1000 or such)

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Feb 2, 2013

Contributor

@graydon Yes that is what I mean here by 'without a runtime'. Lately I think of 'the runtime' and 'the scheduler' as the same thing. This isn't going to get us to a true freestanding rust any time soon, but I think what people mostly want (and what we need) is to execute rust code without the scheduler. I hope to make it clear which parts of core rely on the scheduler and which don't.

Regarding the issue of updating TLS, I don't yet understand the solution you are proposing and how it relates to our current implementation. Let's talk about it on IRC some time.

Contributor

brson commented Feb 2, 2013

@graydon Yes that is what I mean here by 'without a runtime'. Lately I think of 'the runtime' and 'the scheduler' as the same thing. This isn't going to get us to a true freestanding rust any time soon, but I think what people mostly want (and what we need) is to execute rust code without the scheduler. I hope to make it clear which parts of core rely on the scheduler and which don't.

Regarding the issue of updating TLS, I don't yet understand the solution you are proposing and how it relates to our current implementation. Let's talk about it on IRC some time.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Feb 6, 2013

Owner

r+

Owner

brson commented on e43c5bd Feb 6, 2013

r+

brson added a commit that referenced this pull request Feb 7, 2013

Merge pull request #4619 from brson/exchange
Some work on freestanding Rust: foreign calls, exchange allocator

@brson brson merged commit 6e9298a into rust-lang:incoming Feb 7, 2013

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