Of course, I should have known this, since I have relied on this so that I can changed the metadata format without worrying about backwards compatibility. That’s what I get for writing blog posts late at night.
Anyhow, the good news is that we are able to serialize and deserialize AST trees faithfully, and I have written (but not tested) the code to serialize the side tables. I am now working on the deserialization code and the pass which will instantiate sources to be inlined.
]]>This because particularly important because Rust is self-hosting. In particular, the compilation process begins by compiling the standard libraries for use by later stages. But if we change the form of the AST, the snapshot compiler that bootstraps our compilation will still be generating the older AST—so we had better have a way of reading it!
I am not really sure what’s the best way to handle this. I had always assumed that one we reach 1.0, we would just keep a version of that AST module around forever, and convert to the newer AST formats. This is a somewhat painful but acceptable price to pay, so long as the set of versions is not too high. But this scheme looks less attractive if we have to do it for every field that we add to the AST.
In addition, there is another wrinkle I hadn’t really thought about: alongside the AST, we also store the results of various analyses which are used during code gen. For example, there is an analysis that indicates whether a variable is mutated, or whether a particular copy can in fact be implemented with a move. If new analyses are added in the future (and they will be), we won’t have results available for older crates, so we will have to be sure we can always get by without those results. In most cases, though, these results are just used to generate faster code, so we can always generate less efficient code without a problem. But it is something that we nonetheless have to be aware of—and it affects how the side table information is stored. For example, keeping a set of variables that we can optimize better is good, but keeping a set of variables for which we must be conservative is bad. This is because if the set leads to optimization, we can always just use an empty set without affecting correctness. But anyhow this can all be handled with some code.
Anyway, what would be nicest is to have attributes into the AST to indicate what kind of values should be provided for fields that are missing and so forth. This would mean that the serialization code would have to get somewhat smarter, so that it can cope with things like a record with fields that may or may not be present. This is where having automated the serialization process should really pay off, though, since I can make these adjustments once and have all the code be automatically adjusted. Still, I’d have to figure out how to best encode things so that I can figure out what data is present and what is not, and what kinds of changes we should accept.
One note: these kinds of “default-providing” attributes can be dropped once a new snapshot is generated, except in cases where they are required for backwards compatibility to some publicly supported release.
I had rather hoped to avoid these kinds of questions, at least not yet. These seem like detailed questions that are the domain of a specialized library. But I think that they will be hard to avoid so long as we are bootstrapping, as we will always have to deal with executables generated based on the older AST definition.
]]>&. I think, however, that if you
want to allow returning references to the interior of a parameter, you
need a way for the user to denote region names explicitly.
The big problem with returning references to the interior of data structures is ensuring the lifetime and validity of that reference. I think it can be supported in some cases but not particularly well in general. It will work ok for structures allocated on the stack but be quite limited for structures allocated in the heap, unless we have strong support from the garbage collector. Another scenario where it could work well would be user-managed memory pools (which we probably do want to support eventually).
Let’s start with the simplest case:
type T = {mut f: uint};
fn get_f(t: r&T) -> r&mut uint { &t.f }
Here we have a function that returns a pointer to a field of its
parameter. On the callee side, I think this is fairly
straightforward. You name the region in which the parameter is
located (r) and say that the return value is a mutable pointer to
uint in the same region (r&mut uint). The notation may leave
something to be desired, but the concept is hopefully clear enough.
But what about the caller? Again we’ll start with the simplest case,
where get_f() is invoked with data that lives on the stack:
fn caller_on_stack() { // let region `b` refer to the function body
let t = &{mut f: 3}; // type of t: `b&T`
let p = get_f(t); // type of p: `b&mut uint`
*p = 5; // legal, `b` region is in scope.
}
In this case, there is no concern about memory management per se. The
returned pointer is in the region b. The type checker will enforce
the rule that if a function returns a reference type, the reference
must be in scope (note: I haven’t thought through what this means for
generic types with the ref kind, but I guess they can be handled one
way or another). Generally, because the parameter regions must be in
scope for the call, the returned region will be in scope too—but
we’ll see that this does not always hold.
Let’s move on to a more complicated case where the data being accessed is in the heap. I’ll first discuss how it could work in some theoretical world and then show how this can cause problems:
fn caller_on_heap() { // (note: not fully sound)
let t = @{mut f: 3}; // type of t: `@T`
let p = get_f(t); // type of p: `@mut uint`
*p = 5; // legal, `@` region is in scope.
}
The only difference is that the variable t is in the heap region
@. Now the returned pointer is considered to be in that region as
well, and so the assignment is permitted. This seems reasonable at
first, but it is of course incompatible with ref counting (p is not
a ref-counted entity). If we moved to a garbage collector which could
handle interior pointers, this would be reasonably safe. Interior
pointer support is needed to accomodate cases where p gets returned,
like this one:
fn caller_on_heap_r() -> @mut uint {
let t = @{mut f: 3};
ret get_f(t);
}
So is there anything we can do that is compatible with ref. counting? The answer is “sort of”.
One thought is that we say that @ is not actually a region. It’s
never been the best fit, due to ref counting requirements and implicit
headers. Instead, we say that regions always refer to some
block-scoped slice of the program execution. The most common case
would be a block in the program, but in some cases the region might be
“the time in which a given expression is evaluated” and so forth (as
an aside: this is basically what I called an “interval” in my
thesis…minus all the parallel parts).
An @T pointer could then be implicitly coerced into an r&T pointer
where the region r is the biggest region for which the type checker
can guarantee the validity of the @T pointer. So, we can now
revisit the previous examples. The first example works more-or-less
the same as before:
fn caller_on_heap() { // region of the block is `r`
let t = @{mut f: 3}; // type of t: `@T`
let p = get_f(t); // type of p: `r&mut uint`
*p = 5; // legal, `r` region is in scope.
}
The differences here lie in the type checker. The pointer p is no
longer in the @ region but rather in the region r corresponding to
the function body. The reason that the region r could be safely
used is that t is an immutable local variable (I am assuming
issue #1273 is implemented…working on that right now).
This means that the memory will remain valid as long as t is in
scope.
EDIT: There is no reason to impose the following restriction. See
discussion below. This implies that if t were mutable, the example
would not work In that case, the validity of the memory to t could
not be guaranteed for the entire block, as t could be overwritten.
In other words, a program might do something like this:
fn caller_on_heap() {
let mut t = @{mut f: 3};
let p = get_f(t);
t = @{mut f: 22}; // original memory is now freed
*p = 5; // memory error.
}
However, such a program would not type check. The reason is that,
because t is mutable, when t was coerced to a region type, a
narrow region s would be assigned. The region s would correspond
to precisely the call to get_f(). The result of get_f() would
therefore have type s&mut uint, but the region s would be out of
scope after get_f() returned, and so a type error occurs (this is
that rule I mentioned before: when returning a reference, the region
must be in scope).
As an aside, coercing a unique pointer ~T into a region would work
similarly to the second case: that is, the resulting region is always
a very narrow one. It does not matter if the variable storing the
unique pointer is immutable or not. The reason is that the local
variable is being borrowed for the lifetime of the region. If we
assigned a large region, the local variable would be inaccessible
after the call, because we would not be able to guarantee the
uniqueness invariant, as there might be escaped region-typed pointers
into its interior. Anyway, I don’t want to go into details about
unique pointers in this post as it’s already plenty long.
EDIT: pcwalton pointed out to me that there is no reason to treat
mutable variables specially. Instead, we can basically just increment
the ref count whenever we coerce an @T to a r&T. The region r
would still be the region of an enclosing block b (probably the
innermost one, or perhaps the one where the variable is declared) and
we would release the reference upon exiting the block b can still
optimize immutable variables to not increase the reference at all
because it is unnecessary. I rejected this approach initially because
I was thinking that we would want to keep it very predictable when
references would be dropped, but that’s not actually an important
property. Garbage collection traditionally does not define precisely
when dead memory will be reclaimed, after all (and, as graydon
correctly points out, RC+CC is garbage collection). Note though that
borrowing unique pointers probably still ought to use a narrow region
corresponding to the call or alt statement in which the borrow
occurs.
So, I think this system I showed above is reasonable. I think it has a clear story, too, which is important to me, because it helps me believe that it is sound even though I haven’t made any kind of formal proof or argument. The story is basically that
@T is coerced into a region pointer, the result is the largest
region for which the validity of the @T pointer can be guaranteed;~T is coerced into a region, the result is a narrow region
corresponding to just the duration of the borrow (I haven’t gone into
details on this… perhaps in a later post)However, in all of these examples I showed only the simplest case, where a pointer was returned directly into one of the parameters. A more realistic scenario is probably returning some interior pointer to a record reachable from a parameter. For example, a common C trick is to have a hashtable lookup not return the value which was found but rather a pointer to the value. This allows the caller to update the value without having to use any further API calls. Let’s look at that example: we will find that the regions don’t scale up.
The prototype for such a function might be:
fn get_value_ptr<K,V>(m: r&map<K,V>, k: &K) -> option<r&V> {
...
}
This looks reasonable, but once we start digging into the details things don’t work so well. Let’s assume a hashmap with chains for each key:
enum bucket<K,V> = {k: K, mut v: V, mut next: option<@bucket<K,V>>};
enum map<K,V> = {buckets: [mut option<@bucket<K,V>>], ...};
fn get_value_ptr<K,V>(m: r&map<K,V>, k: &K) -> option<r&mut V> {
let bkt_idx: uint = find_bucket_index(m, k);
alt search_bucket_chain(m.buckets[bkt_idx], k) {
none { none } // no bucket with key k
some(bkt) { // found a bucket with key k
// bkt has type @bucket<K,V>
some(&bkt.v) // (*) error
}
}
}
The example should be straightforward if you’ve ever coded up a
hashtable. The tricky part is marked with a (*): once we’ve found
the bucket containing the value, we attempt to return a pointer to its
interior. But this is not safe, of course! The caller expects a
pointer in the same region as the map: that is, with the same
lifetime. There is no way for get_value_ptr() to guarantee that
bkt is valid as long as the map m is valid. The caller might, for
example, remove the key from the hashtable, thus invalidating the
bucket. This error manifests itself as a type error, because the type
of &bkt.v is a region pointer corresponding to the region of the
alt, not the region r which was provided as a parameter.
I don’t think it can without a lot of work. You could imagine that the caller would consider the map “borrowed” while the returned value is in scope and thus try not to modify it. But there may be aliases to the map, so there are still no guarantees.
I think there are two ways to handle an example like that in a safe fashion:
The second “solution” is what we support today, and what is supported by the “Regions Lite” idea I described before. You would write:
fn get_value_ptr<K,V,R>(
m: r&map<K,V>,
k: &K,
f: fn(option<&mut V>) -> R) -> R {
...
}
In other words, the get_value_ptr() method will call the closure f
with the result of the lookup. In this way, the get_value_ptr()
method itself can guarantee that the reference is valid.
It may still be worth having labeled region parameters and supporting a limited form of returning references, but I am not sure. I feel like writing things in a “top-down”, CPS-ish style is perhaps just a better solution—it’s certainly more widely applicable.
Regardless, I do like the idea of formalizing regions as representing
a slice of time, and defining coercions from @T and ~T. I think
that feels intuitively sensible and I think it can be explained in a
reasonable way.
There is however one potentially important future case where the
simple form of returning references would be enough. If we had
user-defined memory pools, then it would be possible to have large,
dynamically allocated, multi-object data structures that all lie
within one region (the memory pool). A map, for example, might have
an associated arena. This scheme would then work. When you think
about it, treating @ as a region and having a GC which can handle
interior pointers is really the same thing as this scheme, from an
abstract point of view.
Another important thing is that I think there is a path from all of
these more limited forms to the more general ones. If we say, for
now, that @ is not a region and we do not support labeled
parameters, we can add both of those later. Existing programs will
continue to type check.
You would have four kinds of Rust pointers:
@MT --- pointers to task-local, boxed data
~MT --- pointers to unique data
&MT --- safe references
*MT --- unsafe, C-like pointers
Here the M refers to a mutability qualifier (default, mut, or
const) and T refers to a type.
&MT types, called references, are the new addition. A reference is
a pointer which always points at memory whose validity is guaranteed
by some outer stack frame. The idea is that a caller can give a
callee a reference to some memory that the callee may use but which
may not escape the callee. This memory may be on the caller’s stack
frame or it may be a reference into the task or exchange heaps which
the caller is going to keep valid. This guarantee is upheld by the
type system.
Reference types may appear anywhere. However, if they are used within
another aggregate type such as a record, enum, or class, they “infect”
their container so that it too is considered to be a reference. This
is done by introducing a new kind into the type system, ref
(actually, this is sort of a negative kind: more formally, there is a
kind heap which contains all types but for those that may
transitively include a reference). This kind may or may not be user
visible: see the section on generics for a discussion of the options.
The type &MT is not a supertype of @MT and ~MT, but it is
coercable. In the case of @, we could probably make it a true
subtype, but at the moment a box pointer includes a header, ref count,
etc and so is not binary compatible with a & pointer, which would be
just a pointer to the box body. If we changed our representation so
that @ pointers point directly to the box and the header is stored
at a negative offset, then we could allow @T to be a subtype of
&T.
The type ~MT, however, can never be a subtype. ~ is not a region.
Rather, the data at the other end of the pointer logically belongs to
a region of its own. So we can allow ~MT to be coerced to &MT,
but the region will be a fresh region, and access to the ~MT pointer
must be prevented for the scope of that fresh region. This is called
“borrowing” a unique pointer. It is only possible for “unique paths”,
where a “unique path” is a path of identifiers a.b.c...z that is the
only path by which the unique variable can be reached (in practice,
this means that a must be a local variable and all of the fields
b...z must have unique or interior type). All of the prefixes of
the unique path must be considered borrowed as well. I am not going
into great detail on the handling of uniques here: it should be quite
similar to what we have today in practice.
Although the user never needs to write it explicitly, each instance of
a reference type is internally associated with a region. There is one
region for every block in the code. In addition, each function/method
has a special region called caller. For simplicity I do not
consider classes nor impls; it is relatively straightforward to extend
the system to such cases.
Regions are arranged into a tree derived from the structure of the
blocks in the source code. The region caller is a superregion of
all the internal regions to a function.
In the implementation / formal version of the type system, these
regions are represented explicitly. So a user-written type &MT
expands to a type r&MT where r is the node id of the block or of
the function itself (in the case of the caller region). The region r
is derived from the position where &MT appears and by inference:
&MT appears within a parameter list, r is the caller region.&MT appears on the type of a local variable, inference is used.&MT appears in a type declaration, see section below.In general, the type a&T is a subtype of b&T if b is a subregion
a. The reason is that, because a is a superregion of b, the
pointer a&T is always valid whenever the region b is valid.
The rules for which region is assigned when the user writes &MT
omitted one important case: what happens when this type appears in a
type declaration? Consider the following example:
type crate_ctxt = {
mut_map: &map<...>,
node_map: &map<...>,
another_map: &map<...>,
yet_another_map: &map<...>
};
In such cases, the region for the internal references will be assigned when the type is used. For example:
fn trans_foo(ccx: &crate_ctxt) {...}
Here, the type of ccx will be expanded to:
caller&{mut_map: caller&map<...>, node_map: caller&map<...>, ... }
In effect, types which contain references (transitively) are implicitly parameterized by a region parameter. There is only one such parameter. When the type is instantiated in a specific context, the value for that parameter is provided based on the context.
The unary operator &M can be be used with both lvalues and rvalues.
When used with an lvalue, it takes the address of the lvalue. The
mutability qualifier provided must agree with the mutability of the
lvalue. When used with an rvalue, it creates temporary space on the
stack and copies the rvalue into it.
Here is an example of taking the address of lvalues:
fn foo() { // region for this block is "r"
let x = 3;
let mut y = 4;
let px1 = &x; // OK: yields type r&int
let px2 = &const x; // OK: yields type r&const int
let px2 = &mut x; // Error: x is immutable
let py1 = &y; // Error: y is mutable.
let py1 = &const y; // OK: yields type r&const int
let py1 = &mut y; // OK: yields type r&mut int
}
Here is an example of taking the address of rvalues:
fn foo() { // region for this block is "r"
let p1 = &{x: 3, y: 4}; // OK: yields type r&{x:int,y:int}
let p2 = &mut {x: 3, y: 4}; // OK: yields type r&mut {x:int,y:int}
}
In order to guarantee that reference types do not escape the callee, the type system imposes some limitations:
ref kind.I will cover each restriction in turn. First, though, I want to more precisely define what the type checker considers to be a reference type. The definition is inductive:
&MT;@&T or
{x: &T}, or a class with a field of reference type);ref.The danger here is that the callee may pass back a reference to the caller that is no longer valid. This is relatively straightforward to prevent: do not allow the return type of a function to be a reference type.
It is not allowed to copy a reference type into a boxed/unique closure
nor is it allowed to cast a reference type to a boxed or unique iface.
The reason is that these are the points where the type system loses
the ability to track the constituent types and so we cannot
distinguish a fn@() that closes over a reference type from other
fn@() types.
There is of course a concern that the limitations on reference types
might be circumvented through the use of generics. This is prevented
through the use of a type kind ref. A generic type variable may not
be bound to a reference type unless it includes the bound ref.
Moreover, any generic type variables bound by ref are considered
reference types and therefore must obey the above restrictions.
In general, ptr types like &MT or @MT are covariant in T if M is
not mut. This is different from references today which are always
covariant in T; the current behavior is what leads to the type hole
pointed out in the mailing list.
For those of you who don’t care about the intimate details of Rust task generation, sorry, this is a kind of a “document the idea” sort of post. I’m sure I’m also brushing over some of the Rust-specific context that might be needed to make the examples easy to understand.
Our basic task builder data types looks like:
type task_builder = ~{
stack_size: uint,
notify_chan: comm::chan<result>,
... various options ...
gen_task_body: fn@(fn~()) -> fn~
};
type task_id = uint;
enum task_result { tr_success, tr_failure };
Basically it’s a struct with a bunch of options. The most interesting
part is the gen_task_body() field, which contains a closure
that—given the user’s task body—will return the real task body.
This allows us to accumulate transformations on the body.
Creating a builder implicitly sets it up with the default options:
fn mk_task_builder() -> task_builder {
fn identity(f: fn~()) { f }
ret ~{ ... default_options ..., gen_task_body: identity };
}
Then people can add impl methods to configure the builder. Here is
one simple example:
impl task_builder for task_builder {
fn set_stack_size(ss: uint) {
self.stack_size = ss;
}
}
Here is an example of how we could make tasks that send a message to a channel when they fail:
impl task_builder for task_builder {
fn notify_chan_on_failure(ch: chan<task_result>) {
self.gen_task_body = fn@(body: fn~()) {
fn~[copy ch, move body]() {
let _ = resource send_final_msg {
comm::send(
ch,
if rt::is_failing {tr_failure} else {tr_success})
}
body();
rt::await_all_children();
}
};
}
}
The effect of this code is to replace the gen_task_body closure with
one that will wrap the user’s supplied body. The wrapper will await
all children created by the body and send a message at the end. The
message will indicate whether it failed or not. The final message
send is written using an inline resource (no syntax exists for this,
but I just didn’t want to write out the full resource declaration that
is currently required).
This is a pretty basic mechanism. It could be wrapped up to be a bit more widely applicable using wrappers like so:
impl task_builder for task_builder {
fn make_joinable() -> future<task_result> {
let port = comm::port();
self.notify_port_on_failure(port);
future::from_port(port)
}
fn notify_port_on_failure(p: port<task_result>) {
notify_chan_on_failure(comm::chan(ch));
}
}
Finally, the spawn method looks like this:
fn spawn(-builder: task_builder, body: fn~()) -> task_id {
let body = builder.gen_task_body(body);
ret rt::spawn(self, body); // do the *actual* spawn
}
One interesting design choice was to make the task_builder unique
and have it be consumed by spawn. The idea was to prevent people from
using the same configuration to launch multiple tasks. This is not
safe in general though it may be in some cases: people can still
explicitly copy the builder if desired.
Sometimes there are cases, like the actor module, where you want to
spawn the task using a different sort of body than a fn~(). The
actor module, for example, expects a body fn~(port<A>) that is
provided with a port. The idea is that you will spawn a task that
creates a port for itself and then sends a channel to that port back
to its creator. This is effectively a wrapper around task::spawn:
mod actor {
enum actor<A> = { t_id: task::task_id, ch: chan<A> };
fn spawn<A>(-builder: task_builder, body: fn~(port<A>)) -> actor<A> {
let tmp_port = comm::port();
let tmp_chan = comm::chan(port);
let t_id = task::spawn(builder, fn~[copy tmp_chan; move body]() {
let port = comm::port();
comm::send(tmp_chan, port);
actor_body(port);
body();
};
let ch = comm::recv(tmp_port);
actor({ch: ch, t_id: t_id})
}
}
It would actually be possible to move the actor body stuff into the
builder, but the resulting module is a little weird and error-prone to
use. Basically it ends up being another kind of thing that wraps
gen_task_body(), and the danger is that if the user doesn’t invoke
the notify wrappers first, you get in a situation where the actor code
is executing before the notification wrappers get setup. Probably not
what you wanted. So we decided it’s better to separate out spawn
functions, which provide the real body of the task, from configuration
wrappers. There may still be ordering dependencies between wrappers but
it’s no doubt fewer.
All of this kind of assumes a simple future module which I think looks like:
mod future {
enum future<A> = {
mutable v: either<A,port<A>>
};
impl future<A> for future<A> {
fn get() -> A {
alt self.v {
either::left(v) { v }
either::right(p) {
let v = comm::recv(p);
self.v = either::left(v);
ret v;
}
}
}
}
fn from_port<A>(p: port<A>) -> future<A> {
future({v: left(p)})
}
fn from_value<A>(v: A) -> future<A> {
future({v: right(p)})
}
}
To make futures more convenient to use, a function like
mod future {
fn spawn<A>(f: fn~() -> A) -> future<A> {
let port = comm::port();
let chan = comm::chan(port);
let builder = task::mk_task_builder();
task::spawn(builder, fn~[move f, chan]() {
let v = f();
comm::send(chan, v);
});
from_port(port)
}
}
would let you write code like:
let f = future::spawn {|| some_expensive_computation() };
...
let r = f.get();
Horray.
]]>So here is a more limited proposal. There is a core task API that looks something like this:
enum task = uint; // wrap the task ID or whatever
type opts = { ... };
fn default_opts() -> opts;
fn spawn(opts: opts, body: fn~()) -> task;
The options struct will let you control simple things like stack size and so forth.
On top of this there will be several patterns. These probably live in
separate modules. For example, an actor pattern which starts up a
task with its own mailbox:
enum actor<A> = {
task: task::task,
chan: comm::chan<A>
}
impl actor<A> for actor<A> {
fn send(msg: A) { comm::send(self.chan, msg) }
}
fn spawn<A,R>(
opts: options,
body: fn~(p: comm::port<A>) -> R) -> task<A,R> {
let pp_tmp = comm::port();
let ch_tmp = comm::chan(p);
let t = task::spawn(opts) {||
let p = comm::port();
comm::send(ch_tmp, comm::chan(p));
body(p);
};
let ch = comm::recv(pp_tmp);
actor(t, ch)
}
Or a futures-like pattern that spawns off a task and allows you to
invoke a get() method to read its result:
enum future<R> = {
task: task::task,
mutable rslt: either<R, comm::port<R>>
}
impl future<A> for future<A> {
fn get() -> R {
alt self.rslt {
either::left(r) { r }
either::right(p) {
let r = comm::recv(self.port);
self.rslt = either::left(r);
ret r;
}
}
}
}
fn spawn<R>(
opts: options,
body: fn~() -> R) -> future<R> {
let pp = comm::port();
let ch = comm::chan(p);
let t = task::spawn(opts) {||
comm::send(ch, body())
};
future(t, either::left(pp))
}
The downside of this approach is that it is not particularly composable (you can’t, for example, combine a future and actor together in one task without writing your own code). However, it’s easy enough to understand and it’s probably good enough.
Hmm, that last sentence makes me wonder if classes and traits could help here. Oh well, a thought for another day.
]]>Product come to mind).
Anyway, Rust does not (yet?) have reflection, but I have been working on a program which will autogenerate the serialization code for our AST based on the type definitions itself. Normally, I would probably do this with some Python program and a bunch of hacky regular expressions. But instead I am taking advantage of one of Rust’s nicer (and somewhat unusual, although becoming less so) features: the fact that the Rust compiler is itself a library. (An aside: I plan to implement this serialization code as a syntax extension or macro once those systems mature.)
To use serializer, you provide it with a crate file and a set of
type names. It will then generate Rust code that serializes instances
of those types. Internally, it invokes the compiler to parse and type
check the crate, using the compile_upto() function, which allows you
to compile a given input up until a certain point (in this case, up
until the type checking phase has completed).
An aside: This is the point where the beauty of crate files becomes more
apparent: a crate is a self-contained specification that not only
contains a listing of the source modules and so forth, but also the
external crates that are required, default compilation options, etc.
Having all of this mess encapsulated in a crate means that it is
trivial for a tool like serializer to recreate the compilation
environment for your package: just provide it with a crate file. If
this were a C program, you’d also have to supply a random smattering
of gcc options, which you would in turn have to figure out how to
extract from your makefile, not to mention the makefiles from external
packages that you are using. Ugh.
Once serializer has parsed and type-checked your source, it is
provided with a crate AST and a type context (ty::ctxt). Using
these two things, it’s fairly straightforward to locate the
definitions for the types we are supposed to serialize and walk over
them, generating code as we go.
The actual code works by walking ty::t instances. ty::t is the
type used in the Rust compiler to represent types. This is distinct
from ast::ty, which is the syntax tree that represents a type.
ty::t is modeled after the type system in the abstract, which makes
it easier to work with. The other reason to walk ty::t instances
and not ast::ty is that there is no AST available for types defined
in external crates (such as option::t, defined in libcore).
Basically, for each unique ty::t that we encounter we generate a function
of the form:
fn serialize<C: serialization::ctxt>(cx: C, t: T) {
...
}
Here T is the type represented by the ty::t. The variable cx is
a serialization context. This is defined using an interface
serialization::ctxt, which looks like so:
mod serialization {
iface ctxt {
fn emit_u64(x: u64);
fn emit_i64(x: i64);
fn emit_record(f: fn());
fn emit_field(f_name: str, f_id: uint, f: fn());
fn emit_enum(e_name: str, f: fn());
fn emit_variant(v_name: str, v_id: uint, f: fn());
...
}
}
So, for example, the serialization function for a type {x: uint, y: uint}
would look something like:
fn serialize1<C: serialization::ctxt>(cx: C, &&v: {x: uint, y: uint}) {
cx.emit_record {||
cx.emit_field("x", 0) {||
cx.emit_u64(v.x as u64);
}
cx.emit_field("y", 1) {||
cx.emit_u64(v.y as u64);
}
}
}
Now, to deserialize, we generate similar code for a deserialization interface:
fn deserialize1<C: deserialization::ctxt>(cx: C) -> {x: uint, y: uint} {
cx.read_record {||
let x = cx.read_field("x", 0) {||
cx.read_u64() as uint
}
let y = cx.read_field("y", 1) {||
cx.read_u64() as uint
}
{x: x, y: y}
}
}
The deserialization interface looks like:
mod deserialization {
iface ctxt {
fn read_u64() -> u64;
fn read_i64() -> i64;
fn read_record<T>(f: fn() -> T) -> T;
fn read_field<T>(f_name: str, f_id: uint, f: fn() -> T) -> T;
fn read_enum<T>(f: fn(uint) -> T);
...
}
}
A somewhat more interesting case concerns enums. Let’s consider the
enum option<R> where R is the record type we’ve been working with.
It would be serialized as:
type R = {x: uint, y: uint};
fn serialize2<C: serialization::ctxt>(cx: C, &&v: option<R>) {
cx.emit_enum("std::option::t<R>") {||
alt v {
none {
cx.emit_variant("std::option::none", 0u) {||
}
}
some(r) {
cx.emit_variant("std::option::some, 1u) {||
serialize1(cx, r); // link to the previous code we saw
}
}
}
}
}
The deserializer meanwhile would look like:
fn deserialize2<C: deserialization::ctxt>(cx: C) -> option<uint> {
cx.read_enum {|v_id|
alt v_id {
0u { // std::option::none
std::option::none
}
1u { // std::option::some
std::option::some(deserialize1(cx))
}
_ {
fail #fmt["Unexpected discriminant %u for option::option",
v_id];
}
}
}
}
loop_ctl type.This was my original proposal. Basically, there will be a type
called iter::loop_ctl defined as so:
enum loop_ctl { lc_break, lc_cont }
I wanted to design something that felt as much like normal loops as
possible. So my thought was that, for sugared closures where the
return type was loop_ctl, the compiler could insert lc_cont as the
tail expression should there not be one already.
The idea then was to change vec::iter() from a function with the signature:
fn iter<T>(v: [T], f: fn(T))
to the following:
fn iter<T>(v: [T], f: fn(T) -> loop_ctl)
In other words, the function supplied to iter would be allowed to
break the loop in the middle if it wanted to. Due to the default
rules, this is mostly invisible, except that you can say break and
cont and things work as you expect.
Unfortunately, as I think more about it, I realize that the default rules aren’t quite subtle enough. It’s only mostly invisible. For example:
vec::iter(v) {
while cond { }
}
This would fail because while loops have a result type of (), and in
this case the while loop occupies the tail expression slot. So you would
have to write:
vec::iter(v) {
while cond { }
cont;
}
This makes me unhappy. I’m happy with smart rules but only if they
really work all the time or have a consistent story. You could extend
the rule to say “if the tail expression has unit type, still insert a
default cont”, but now it’s starting to sound really magical.
We can keep the loop_ctl type but just not make it special. Iterable
types define two methods, iter and iter_brk (not sure about those names),
with signatures as shown (these are for vectors:
iface iterable<T> {
fn iter(f: fn(T)) /* as today */
fn iter_brk(f: fn(T) -> loop_ctl)
}
Now when you want to break, you have to end the loop explicitly with cont.
For most types, you need only define iter_brk: the iter function
itself can be defined generically as shown (this assumes traits are
implemented):
trait base_iter<T> {
req fn iter_brk(f: fn(T) -> loop_ctl);
fn iter(f: fn(A)) {
self.iter_brk {|e|
f(e);
cont;
}
}
}
Same as #2, but we replace the loop_ctl type with boolean. This is
appealing because it’s so minimalistic. break would effectively
return false and cont would return true. This makes iter_brk
effectively the same as the predicate test all(), which returns true
if the block returns true for all members.
Of course, if we actually used all() instead of iter_brk that’d be
ok too, except that the return type of all is bool, so a semicolon would
be required:
v.all {|i|
...
};
We could of course have both all and iter_brk (as we would in
alternative #2).
I started out liking alternative #1, but writing this blog post has
more-or-less persuaded me that I prefer alternative #2. Less compiler
magic is good, and compiler magic that fails is bad. Between
alternatives #2 and #3, I tend to slightly prefer an explicit
loop_ctl type over a boolean for a couple of reasons:
break and cont to return out of arbitrary blocks
that happen to return boolean.you can always write helpers like
fn break_if(b: bool) -> loop_ctl { if b { lc_break } else { lc_cont } }
fn cont_if(b: bool) -> loop_ctl { break_if(!b) }
to convert between bool and loop_ctl when convenient.
But obviously there is no substantive difference between alternatives
vec::iter() in our source code. Such methods have proven to be
a very scalable way to define iteration abstracts, but performance is
currently somewhat lacking.
The major language-level issue associated with CCI is that it interferes with separate compilation. I won’t talk about this at the moment; we may choose to only inline when statically linking, or to give users some way to distinguish what can be inlined and what must not be, etc.
What I do want to look at is the best way to implement CCI in our compiler. Right now the compiler is focused on compiling one crate at a time and so a few things will have to change.
pcwalton forwarded me a partial patch which tries to separate out
various parts of the compiler to generalize to multiple crates. I am
not sure, though, that this is worth the effort: after all, we are
still compiling one main crate, we’re just borrowing code from other
crates. Furthermore, we never intend to report errors on the imported
crates: they have typechecked etc, so nothing should go wrong. The
only reason that we will need to know about them at all is for line
number reporting within the compiler. Therefore, I am leaning now
towards keeping things mostly the same, but adding files from inlined
crates into the existing codemap structure where necessary.
Another question is how to make the AST available within a compiled crate; the inliner will need to reference it to produce an inlined version, after all. There are a couple of dimensions here. The first is how to serialize the AST at all—the easiest way is to use the Rust pretty printer. The best way, I think, is to write the tree out in EBML. The reason for this is that it allows to retain the spans from the original source, which will be lost by the pretty printer. It also allows us to keep the various information we keep in side-tables, such as the type associated with each node. We may nonetheless start with pretty printed source and change later, if that proves expedient.
The second dimension to the question of serializing source is at what granularity to do it. Graydon has pointed out that we should be sensitive to the compile-time impact of inlining and monomorphization, and I agree. However, we are primarily interested in the compile-time impact on debug-mode compilations, meaning that inlining would probably be disabled. Nonetheless, we should be careful about how we package up the source for three reasons: (1) monomorphization, when it occurs, will require access even in debug mode; (2) if we play our cards right, we may be able to consolidate some of the control paths we use in type checking and elsewhere (more on that in a bit); and (3) having faster compile times even with optimizations enabled never hurts.
This suggests to me that we do not want to include the source for an entire crate at a time. It seems like items are the logical level for this. I am wondering if we could encode the module structure using EBML but at each top-level item we stop and encode two things: the signature of the item as well as the source. Currently, we encode the signature using EBML, and perhaps we can just keep that path, though it may be easier to pretty-print the signature and then parse it again.
Why would that be easier, you ask? After all, the current system works, right? Well, the idea (hat tip to pcwalton here) is to consolidate some of the logic in the compiler. Currently, everytime we resolve the type of an item, we must ask “is it in the current crate or not?” If it is, we go through one path, which involves looking up the AST and other internal tables. If it is not, then we look into a crate metadata cache and—if needed—reconstruct the signature by parsing EBML. So my thought is that perhaps we can bring these paths together by filling in the AST and other information lazilly, extracting what is needed out of the crate.
Actually, the question of pretty-printing vs EBML is somewhat orthogonal, I suppose. In fact, it might be better to keep the EBML for the reasons discussed earlier (easier to reconstruct the various side table information that is required).
So, I am starting to see a high-level vision for how this might all be organized, but I don’t know these paths of the code that well, so I might turn out to be rather confused. It’s also a bit unclear to me if consolidating the paths through the compiler is important to CCI or just a nice thing to do. I’d rather get results first and work on refactoring second.
]]>First, we made our 0.1 release, which is great. We are now planning for 0.2. The goal is to make frequent, relatively regular releases. We’re still in such an early phase that it doesn’t seem to make sense to literally release every few months, but at the same time we don’t plan to wait long.
Lately I’ve been working on several issues, some major, some minor. The most exciting to me has been #1493, which vastly improved our performance when working with thread-local boxes. There is still work to be done on box performance, but before taking any next steps more investigation is needed. The problems may be creating type descriptors, they may be garbage collection, etc. This is also a first step to simplifying some of the scarier parts of the Rust runtime.
On a smaller note, I’ve been working on a new iteration library that I’m reasonably excited about, based on the principles from an earlier blog post. Making it nice to use will require a lighter bind syntax, which I’ve almost got complete now. This also (as a side effect) improves our type inference somewhat. One final thing I’d like to do is integrate support for break and cont into the library, though some details remain to be discussed there.
Finally, I’m beginning work now on cross-crate inlining. I plan to
write a post later exploring some of the dynamics of this. It’s an
interesting problem. It’s clearly important for performance, though:
functions like vec::iter() are used ubiquitously and we need to be
able to inline their definitions. This is also where Rust’s emphasis
on static dispatch can really pay off (not that it is not helpful
already at reducing dispatch costs).
I have been progressing on the parallelism work that occupied the last few posts. First, the parallel JavaScript work now has an official name: the PJs project. That github project is not that useful at the moment, though: I am in the process of moving the code from an older GitHub project into the new one which contains the rest of mozilla-central.
What exists today is a (very) simple multi-threaded infrastructure that will run JavaScript functions in parallel, multiplexing them over a fixed number of workers. Right now though there is no data sharing between threads. I am working on the membrane approach.
I have also had some discussions with the Rivertrail group. The Rivertrail definition of an elemental function dovetails very well with my own ideas, so it seems like the two projects could be fruitfully combined: the PJs API can be used both for task-based parallel tasks and for those instances where vectorization either fails or is not effective.
Finally, I drew up a Java-based prototype of the API as well as the static type system that I described earlier. Having this prototype gives me confidence that the approach will work, as I found it quite easy to parallelize a number of interesting examples.
Man, I didn’t realize how much stuff has been going on. No wonder I haven’t had time for blog posts! And this isn’t even a complete list, really. But it’s everything that’s interesting, I suppose.
]]>The better answer is that I don’t think that Erlang’s actor model and the model I propose are that far apart. I see this model as a kind of “delimited actor”. Why would I say that, since it does not seem to resemble actors at a superficial level? The reason is that, in my model, each child is quite isolated from one another. In a typical “shared memory” model, processes communicate by modifying common data structures. This turns out to be highly unreliable.
In the model I propose (which needs a name), processes may share data structures, but they cannot communicate this way, as those structures are immutable. In fact, the only way that sibling processes can communicate with one another is by joining each other. This allows them to recieve the other processes result. This is effectively a one-shot message from one task to another.
So, in a way my model is a simplification of actors: it allows you to spawn a set of actors. The parent data which they share is effectively an initial message from the parent to each child. The child’s result is then a one time message from each child to the parent (or to other siblings in a DAG-like fashion).
I don’t actually think my model is a good choice as the only model for parallelism in your language, but I think it complements actors quite well. Consider what you would do in Erlang if you want to process the members of a list in parallel: you would create a task for each member of the list and send it whatever context is requires. You would then receive back the new values and construct the new list. In other words, you would implement precisely the messaging pattern that this model defines.
Of course, as often happens, supporting only a limited model for messaging lets you optimize things in the implementation. Because we know that the child processes are only of limited duration, we don’t have to copy the parent’s data but can instead allow them to reference it (readonly) directly. Similarly, because we know that each child is dead when its result is received, we don’t have to copy the result into the parent’s address space, but can again reuse the values directly. Finally, the garbage collector does not have to consider the case of cross-process garbage collection: the parent’s data is immutable, so whatever is live will remain live. The data accessible to each child is disjoint, so we can collect data owned by each child independently without looking at the others.
I am tempted to call my model “delimited actors”, but I think it looks sufficiently different from actors that this name might be misleading. But, as I just argued, I think it is closer to actors than to the “shared memory” model that has caused so many problems and difficulties.
]]>The model is that a JavaScript worker (the “parent”) may spawn a number of child tasks (the “children”). The parent is suspended while the children execute, meaning that it will not process events or take other actions. Once the children have completed the parent will be re-awoken.
Each object in JavaScript is owned by the task which created it. Children may access all of the objects of their parent, but only in a read-only fashion. This is enforced dynamically. When a task completes, its objects become owned by the parent. Therefore, the child tasks may create data and operate on it in a mutable fashion; when they finish they can return some of this data to the parent as their result. When the parent resumes, they are now the owner of the data (as the child has finished) and so they may freely manipulate it.
One nice feature of this model is that the data which a given piece of code has access to is precisely the same set as the data which it is allowed to read. So reads can proceed with no overhead at all (well, in theory; see the implementation section below). Writes require an extra check to guarantee that the object is owned by the task doing the writing (again, in theory; see the implementation section below).
Parallel children will only be usable from web workers. The reason is that the model is inherently blocking (the parent must not execute while the children are executing or we would have dataraces), and we do not want to permit the main UI thread to be blocked.
One last piece of the puzzle concerns arrays and array buffers. I want the option to divide up large arrays and array buffers amongst workers in such a way that each gets a disjoint view into the buffer. Each worker could then read/write into their disjoint view in parallel. Access to the original array or array buffer would yield an exception until all children have completed. The user would select how the view buffer should be divided up (tiled, striped, checkerboard, etc). This will probably be deferred until later though.
I would like to expose the API in two levels. The first would be the more primitive, building blocks API which permits child tasks to be forked and joined. The second would be a higher level API that operates over entire arrays or array buffers. The higher level API would be more than just convenience: it would be needed for creating the disjoint views discussed at the end of the previous section.
To execute in parallel, you begin by creating a scheduler:
let sched = scheduler();
Each scheduler is bound to a parent task, which is always the task which created it. You can use the scheduler to create child tasks which will execute while the scheduler is active. Child tasks can be created in two ways:
let task1 = sched.fork(function() {...});
let task2 = sched.forkN(n, function(idx) {...});
The first, fork(), simply creates a task that will execute the given
function. The result task1 is a task object, which supports the
method get() (more on that later). The forkN() variant creates a
task which will process n items: he function provided as argument
will be invoked once per item, with idx ranging from 0 to n-1.
The individual invocations of this function may themselves occur in
parallel.
Executing the tasks can be done using the execute method of the scheduler:
sched.execute()
This will cause a block parallel phase in which all forked tasks associated with the scheduler execute.
Finally, each task produces a result. For a fork() task, the result
is simply the return value of the function. For a forkN() task, the
result is an array containing all the results (so
[func(0), ..., func(n-1)]).
Whichever way it is created, the result of a task can be accessed using
the get() method. If executed within the parent, the get() method
must be called after the sched.execute() call or else an error occurs.
If executed within a child, the get() method will effectively join the
other task and read its result. The result will then be read-only within
the child.
Building on this low-level API, there is a higher-level API for processing arrays and buffers. I am not precisely sure how this should look, but I think it will be something like:
array.update_in_parallel(strategy, function(ctx, view) {
... array is inaccessible in here; each child task gets
a disjoint view which is a read/write slice of the array ...
});
Here the parameter strategy would specify how the array should be
divided into views. I think the best thing is probably to look at the
X10 and Chapel languages (as well as their predecessors) and see how
they handle the dividing of arrays across distributed processors. We
probably want something similar but (hopefully) simpler. In an ideal
world, strategy would be some sort of functions so that users could
specify how the array is divided, though this opens the door to races
if the function is invalid. Another simpler alternative is to allow
various strings like “tiled”, “striped”, etc.
A plan for a working prototype based on Spidermonkey has begun to emerge. First, the idea would be to have a pool of worker threads that will execute the parallel tasks by drawing on a shared queue (or possibly using work stealing, this is not so important).
The tricky part is how to manage the shared data from the parent task. We need to make that data available to the children in such a way that it can (a) be safely read in parallel and (b) not be modified. You may think that (a) should come for free, but in fact it does not. This is because Spidermonkey optimizes reads, which in JavaScript can be quite complex, by making use of caching and other techinques which do in fact modify the representation of the object being read.
The technique that we plan to use is similar to what is used to protect domains from one another. Each task will have its own compartment. This effect creates a partitioned heap where each task has a separate heap. Then, for each upvar of the parent that must be used from the child, a proxy object (not a JS proxy, but a Spidermonkey proxy, which is a lower level tool) will be created. Reads to this parent object will therefore always go through a proxy: this proxy is responsible for taking a naive read path that does not modify the parent object. This means that reads of parent objects during parallel code will be somewhat slower. However, as a benefit, this proxy can trivially prevent writes to parent objects, so it is easy to ensure that the siblings do not step on each other.
Once a task ends, the data in its compartment can be given to the parent. Basically a compartment contains a number of arena pages. Those arena pages can simply be moved from the child task’s compartment into the parent task’s compartment. The only thing left to do is to replace any references to the proxied parent objects with the actual objects themselves. Note that because the parent objects are immutable, it will not be possible to have references from the parent objects to the child objects, only the other way around. We could also run the garbage collector if we wanted, which would cause all child data not reachable from the child’s result to be collected.
One big advantage of this proxy-and-compartment-based design is that it should not require modifying the JIT or the interpreter. Both of those systems are already aware of proxies and would treat them specially.
]]>A very simple example of what I mean by iterator composition is
Python’s enumerate() function, which converts an iterator over T
items into an iterator over (uint, T) pairs, where the uint
represents the index. This handy little function allows any loop to
easily track the index, no matter what it is iterating over. So I can
write:
for (idx, elem) in enumerate(list): ...
for (idx, elem) in enumerate(dict.keys()): ...
for (idx, elem) in enumerate(dict.values()): ...
for (idx, elem) in enumerate(anything at all): ...
This is very useful.
Now, in Rust, we have a function vec::iter(), defined like so:
fn iter<T>(v: [T], blk: block(T)) {
uint::range(0, vec::len(v)) { |i|
blk(v[i]);
}
}
Suppose that we wanted to write some kind of generic enumerate()
style function that would convert a function like iter into one
that provides indices. I think the only way to do this in Rust is
to write something like:
fn enumerate<S,T>(iter_fn: block(block(T)), blk: block(uint, T)) {
let i = 0u;
iter_fn() { |t|
blk(i, t);
i += 1u;
}
}
This would then be used like so:
enumerate(bind vec::iter(v, _)) { |i, e| ... }
enumerate(bind m.keys(_)) { |i, e| ... }
enumerate(bind m.values(_)) { |i, e| ... }
Overall, this is not too bad. A lighterweight curry syntax would make
it somewhat more pleasant, but I rather like bind as it is, so I
don’t have any concrete suggestions. Besides, after my foray into
expanding the possibilities of block sugar in expressions, I am done
with thinking about syntax for a little while!
I have been working on and off on allowing block sugar to appear in Rust expressions and not only statements. For those who do not know what I am talking about, let me give a bit of context. At the moment, one can write the following in Rust:
vec::iter(v) { |e|
...
}
which is sugar for the function call:
vec::iter(v, { |e|
...
})
Objectively, there isn’t much difference between the two, but somehow
pulling the {||} out of the parentheses feels much lighter to me.
However, today, this sugar is only allowed in statements. That is,
the result of the call to vec::iter() is ignored. For
vec::iter(), this makes sense, since the result is unit. But it
might also be nice to be able to write:
let foo = vec::map(v) { |e|
...
};
or:
let child = task::spawn { ||
...
};
In implementing this, however, I’ve run into a few dark corners of the syntax. I’m trying to find the best way to support such sugar with minimal changes to the language.
Today we attempt to determine in the parser whether an expression may yield a usable value. In the case of expressions that double as statements, this is generally specified by the presence or absence of a trailing semicolon. In the case of blocks and other compound statements, the presence or absence of a semicolon in the final expression within the block is significant. Therefore, we can have something like:
fn foo(...) -> T {
if expr1 {
if expr2 { expr3 } else { expr4 }
} else {
expr5
}
}
This is a function which returns a value. This is very different from the same code with semicolons:
fn foo(...) {
if expr1 {
if expr2 { expr3; } else { expr4; };
} else {
expr5;
}
}
This is code that executes but the result values are ignored.
This system doesn’t work so well with the syntactic sugar, as
vec::iter(v) { |e| ... } and vec::map(v) { |e| ... } both look the
same, but the latter produces a value. Therefore, the parser is
unable to distinguish between them to decide whether the expression
produces a value or not.
This ambiguity only becomes significant if the sugared expression appears at the top-level of a block (e.g., where it can be interpreted as a statement). Here we can distinguish between two cases:
Consider a block like:
{
foo {|| ... }
-10
}
How do I interpret this? Based on the whitespace, it appears to have been intended this way:
{ foo({|| ... }); -10 }
But it could also be parsed this way:
{ foo({|| ... }) - 10 }
I solved this with a simple rule: in a top-level expression, the
block sugar cannot be followed by binary operators, calls, fields,
etc. Therefore, we would parse this block as two statements. I and
others that I have asked find the other alternative (foo {|| ...} -
10 as an expression) visually hard to parse. If you want this, use
explicit parentheses.
Does a block like { foo {|| ...} } produce a value or not? This is
trickier than the other option.
I see four possible solutions to the “tail position” problem, and I summarize them as follows:
Let me spell out these possible solutions in more detail.
This creates a distinction between loops like while {...} and loops
like func(v) {...}; while loops always have unit type but
func(v) {...} may not. Today, however, that produces an error for a
snippet like this:
while cond {
vec::iter(v) { ... }
}
This is because the parser requires that while loop blocks do not have
an expression in tail position, and vec::iter() counts as such a
block. We would therefore require a semicolon in such cases. This
feels weird to me.
We can solve this by modifying the parser. There are a few options,
but I think the most consistent overall is to permit expressions in
while loop bodies and elsewhere, but require them to have unit type.
This means that the above example would work, but a call to
vec::any() would not (it produces a boolean value) and neither would
a tail expression like 10 (it produces an int value). Those would
require a trailing semicolon.
UPDATE: This solution can lead to some complications. Consider code like the following:
fn foo() {
if cond {
vec::iter(v) { ... }
} else {
vec::iter(v) { ... }
}
bar();
}
The first if/else now looks like an expression, because both blocks
produce a value (albeit a value of type unit). In other words, the
if/else is classified the same as an if/else like if cond { 10 }
else { 20 } by the parser. These “value-bearing” if/else expressions
require semicolons. Therefore, the example doesn’t parse. To solve
this, we say that if/else, alt, do/while, and standalone blocks
never require semicolons when used at top-level.
I find this more consistent anyhow. Basically there is a category of
“dual-purpose” (statement and expression) forms. These include
“keyword” expressions (if, alt, while, etc), standalone blocks,
and syntactic sugar calls. If these dual-purpose expressions appear
at top-level, they are a statement. Otherwise, they are an
expression.
We could also say that a top-level expression never produces a value. This feels consistent with the rule for top-level expressions that appear in the middle of a block. However, this solution disallows a statement like:
let w =
if true { vec::any(abs_v) { |e| float::nonnegative(e) } }
else { false };
Here, the call to vec::any() is clearly intended to be used an
expression, but the parser interprets it as a statement, and so we get
a type error expected () but found bool. The problem here is
insufficient context: the block itself appears in an expression
position, so it seems reasonable that the tail position of such a
block be treated as an expression! This leads us to our next
solution.
We can distinguish in the parser between blocks that appear in an expression position and those that do not. The key problem here becomes function items themselves. For example:
fn foo() -> bool {
...
vec::any(abs_v) { |e| float::nonnegative(e) }
}
Is this call to vec::any() an expression? The block here appears as
the body of a function, so it’s a bit hard to say. I would like the
answer to be yes. We could achieve this by examining the return type
of the function being parsed: if it is unit (or unspecified, which
defaults to unit) then we can parse the function body as a block in
statement position. This means that foo() above would parse (and
type check). In bar():
This works well for functions, but the parser doesn’t always have enough context to make this decision:
fn foo() {
vec::iter(v) { |e|
vec::any(abs_v) { |e| float::nonnegative(e) }
}
}
Is this call to vec::any() intended as an expression? As it
happens, vec::iter() expects a block argument with unit result type;
so to follow our context-sensitive rules, vec::any() must be a
statement, but of course the parser doesn’t know that, and so the user
would have to put a semicolon. This leads us to our next solution.
We can have the parser say that the last expression in a block is always an expression and not a statement, and just have the type checker perform the context-dependent reasoning: any time that a block is checked in a context where a unit result is expected, the type of the tail expression is ignored. This makes all of our examples work but is mildly more permissive than the language today. For example, this code would type check:
fn foo() {
10
}
This is because foo() has a unit result type, so the type of the
tail expression (int) is ignored. Most likely the result type of
foo() was accidentally omitted. I think this is acceptable, though,
because the user will notice that the return type of foo() is missing
when they try to call it elsewhere in the code.
UPDATE: This also requires distinguishing “dual-purpose” statements as described in the first solution (“yes, it does produce a value”). In fact, both the first and fourth solution are kind of the same, but the fourth involves a bit more work in the type checker to allow users to omit semicolons somewhat more often.
I don’t know but I am leaning towards the first or final solutions, as they seem the most consistent. To be honest I am most concerned with finding a rule that’s easy enough to explain and understand. I don’t want people to feel that the parsing rules are too confusing.
]]>None of these features are unique to Rust, but the combination is new, and it’s powerful. There are also plenty of small decisions I think are fantastic:
fn and ret were overly terse,
but after working with them writing out return just seems so ponderous.
Similarly, parentheses-free syntax for if is surprisingly pleasant.I could go on but I guess that’s enough. Anyway I think my point is that I think Rust has the big picture down pat. I would like to tweak how it achieves some of those goals but even if my ideas never make it or turn out to be flawed (as some of them no doubt are), Rust’ll be a very nice language to use.
]]>The basic parallel model would be block-scoped parallelism as I’ve been
referring to in the various Rust posts. To make this concrete, here is a
low-level example of how it might work; this is a dynamic version of
something like the finally/async blocks of X10. There are two basic concepts,
a parallel region and a set of parallel tasks. Each task is created within
some parallel region; when the parallel region is executed, all of
the tasks begin exeution. They may continue to create new tasks. Meanwhile,
the task which executed the parallel region blocks until it completes.
def divide_and_conquer(...):
if "small enough to do sequentially":
process(list)
else:
p = parallel_region()
task1 = p.new_task(lambda: divide_and_conquer(...))
task2 = p.new_task(lambda: divide_and_conquer(...))
p.execute()
task1.get_result() # yields an error unless p.execute() has run
I will leave aside for the moment the question of deciding which problems are small enough to do sequentially and so forth. This task and parallel region API is intended to be low-level. Higher-level libraries would build on it to make those sorts of decisions.
Anyway the API is somewhat orthogonal. We could dicker about the precise design, I am more interested in the data-race freedom part. The key properties that the API must maintain are:
Now, the key idea: I want to say that each object is owned by the task which creates it. The data is then mutable only by its owner and any parent task of the owner. The data is readable by the owner and any child task of the owner. These constraints—assuming no global data—suffice to guarantee that a given object cannot leak to siblings of its owner. Only the owner, ancesors of the owner, and children of the owner can have access to the object.
This leaking property is important, so let’s take a second to see why
it’s true: the idea is that two sibling tasks can only communicate via
shared memory. This memory must have existed when the tasks were
created, so it must be owned by a common parent of the sibling tasks.
This common memory is therefore immutable: only the common parent could
modify it, and the comment parent is suspended while its children
execute.
Based on this, we can say that whenever we modify a field of an object, we must check that we are either the owner or a parent of the owner. If we are a parent, then the owner must have terminated (else the parent could be not be active), so we can adjust the owner of the object to be ourselves. Thus the check for “do I have write access?” is kind of a variant of Tarjan’s union set algorithm with chain compression.
Interestingly, no dynamic check at all is needed to do a read: either we own the object, in which case we can read it, or it is owned by a parent or extinct child. In all of those cases reads are permitted.
I’ve phrased this write check as a per-object check, but I think that in an actual implementation, I would really do it on groups of objects; this would be implemented almost exactly like a write barrier in a garbage collected environment, except that we have to not only write out the dirty bit but read it first to check that we have write access. Obviously this will be slower, but not that much slower I should think, particularly as we are likely to be writing to recently created objects, and hence have the dirty bit in cache.
But sometimes we want to be able to pass mutable data to our children. My idea for this is to use a kind of dynamic version of unique pointers. In JavaScript, I would implement this with proxies: basically, you create an object and when you create it, you say it is mobile. What you get back is a proxy to the real object, which is locked within the proxy and never divulged. Now you can use it like any object, but eventually you can give it to a child. Your existing proxy is then set to some broken state and a new proxy created which has the object. This proxy is handed by the runtime to your newly spawned task. The task can always give it back to you by returning it.
I showed this for a simple fork-join model. I think you can rephrase it in terms of futures or something like Dot Net’s parallel tasks as well.
]]>Closures in Rust are represented as two words. The first is the function pointer and the second is a pointer to the closure, which is the captured environment that stores the data that was closed over. Because of how Rust is implemented, the closure must also store any type descriptors that were in scope at the point where the closure was created.
Prior to my changes, the closure was represented by a structure roughly equivalent to this C++ struct (actually I will use a hybrid of C++ and Java syntax):
struct closure<class BD, unsigned n_tds> {
type_desc *bound_data_td;
BD bound_data;
type_desc *bound_tds[n_tds];
};
Here, the initial type descriptor bound_data_td is a type descriptor
that describes the struct BD. It contains, among other things, the
size and alignment of BD etc, as well as pointers to the “take” and “drop”
functions, which copy and release the value respectively.
This layout had a few downsides. One was that we could not load the type
descriptors from the bound_tds array without knowing the type of bound_data.
It’s possible, however, that we do not know the precise type of bound_data
for any specific closure instance. The reason is that the closure might come
from a generic function, something like:
fn make_closure<copy T>(t: T) -> (lambda() -> T) {
ret lambda() -> T { t };
}
Now, this closure is going to result in a bound_data that is itself generic! It would look something like:
struct make_closure_bound_data<class T> {
T t;
};
The problem is that when we are generating code for this closure, we have to generate
one set of code that works for any value of T. In other words, we know that
we have a closure whose type is something like closure<make_closure_bound_data<?>, 1>,
where ? represents an unknown type. Expanded that would look like:
// closure<make_closure_bound_data<?>, 1>
struct make_closure_closure {
type_desc *bound_data_td;
make_closure_bound_data<?> bound_data;
type_desc *bound_tds[1];
};
The problem now is that because we do not know the precise type of bound_data,
we also do not know the offset of the field bound_tds! The way we generally
handle this sort of situation is to use a type descriptor for the unknown type
T tells us how big a value of type T is and so forth. Indeed, we have that
type descriptor, but it is stored in the bound_tds
array above. But now you see a certain chicken-and-egg problem: to know how big the
bound data is, we have to load the type descriptor for T, but to load the type
descriptor, we have to know how big the bound data is.
The solution to this in the past was that we also had the bound_data_td, a type
descriptor for the entire set of bound data, and we could use its size field to
skip past the bound data to the type descriptor array. But this was kludgy and
also dangerous: the code had to use a different code path (for various reasons
not worth getting into) than the other code that does these sort of dynamic
calculations, and I am not sure that it was correctly considering things like
alignment restrictions and so forth.
Therefore, I made some slight changes to the structure that eased these problems. It is now represented like so:
template<class BD, unsigned n_tds>
struct closure {
type_desc *closure_td;
type_desc *bound_tds[n_tds];
BD bound_data;
};
There are two changes of note. First, the closure_td represents the entire
closure and not just the bound data. Second, the set of bound type descriptors
is stored at a statically known offset, regardless of what data is closed over.
What’s more, while it may not be obvious at first, the offset of the bound_data
is also statically known: the reason is that when we are looking at one of these
structures, we know the number of bound type descriptors (i.e., we know n_tds in
the template above), and they are always of fixed size (a pointer). So that’s
good.
Now the other nice thing is that because closure_td represents the closure as a whole,
we can re-use the existing type copying routines. Basically we are able to say:
“copy the object whose type is described by closure_td” and the code will do
the right thing. If closure_td does not involve generic types, it will generate
purely static code, otherwise it will generate hybrid static/dynamic code.
So basically I use these standard routines to generate the glue functions that take
and drop a closure.
Now, if you have a sendable fn in your rust code and want to do a deep copy, you
can use these glue functions. You may be wondering why have to use the glue functions,
why not just copy it directly? The reason is that when you have a sendable fn, you
don’t know the precise closure type: it’s equivalent to a type like closure<?,?>.
However, even that very imprecise type is enough to find the field closure_td,
which is always first, so we can copy any kind of closure by doing:
closure<?,?> *copied_closure = closure;
closure->closure_td->take_glue(&copied_closure);
(That is more-or-less the signature that our take functions have). There are a few other minor changes, but that’s the gist of it.
]]>Anyhow, pcwalton and dherman yesterday pointed out to me
that const is not exactly one of the most beloved features of C++:
“const-ification” is no fun, and if we’re not careful, Rust could walk
right down that path. To some extent my reaction is, “Well,
something’s gotta’ give.” You can’t have modular static race freedom
without some way to know what function will write what. But
nonetheless they are quite correct.
I think the problem with const is that it’s not the default, despite
the fact that most operations are reads. So perhaps we could make
const the default for Rust: I think this would fit with the general
philosophy of making mutation explicit. In practice what this would
mean is that declarations like x: @T, &&x: T, x: [T] would all
be declaring a pointer x to read-only (i.e., const) data. This
would be a deep const. A pointer of type @mut T would permit
modification of the data it points at. (I am not quite sure what to do
with ~; since there is no fear of aliasing, permitting mutation
implicitly makes sense to me but it is somewhat inconsistent).
This makes subtle changes in the meaning of existing types. For
example, [T] no longer means an immutable array but rather what
today would be written as [const T]. We could add an explicit imm
qualifier if we wanted to allow for immutable data: it would be usable
not only on arrays but also on records and the like, so you could
write [imm T] or @imm T. I won’t talk about imm further,
though; the details of its addition are left as an exercise to the
reader (always wanted to write that…).
An important difference between mut and the other qualifiers is that
mut is shallow where the others are deep. For example, given a variable
x: @mut T where the type T is defined as:
type T = {
f: @U, g: @mut U
};
x.f has type @U and x.g has type @mut U. But if we have a
non-mut variable y: @T, then both y.f and y.g have type @U
(the mut on the field g is lost because y is a const pointer).
One final note: in comparison to C, I have only discussed the mut
qualifer in pointer types. For example, @mut T and [mut T].
Types like const int that you can find in C don’t make sense to me:
it’s a value, it can’t be modified, only overwritten. That seems like
a property of the lvalue not the type. But if you want to interpret
things in the C way, then you could say that types are mutable by
default, but pointers are const by default. So the type int is a
mutable int (i.e., a variable which can be changed), but the type
@int is a const pointer to an int. I don’t think this is a very
important point, personally; it sounds like it’s deep but I think it’s
not.
Ok, this is just a sketch, but it’s enough for me to remember what I was thinking later. I am pretty sure this actually hangs together rather nicely (I thought about it a lot on the train and went through various iterations). I am not sure how it would feel to program in, but I suspect it would be very nice. More to come in later posts I’m sure.
]]>fn[send] <: fn <: block
but of course this is not necessary. What is desirable is a partial ordering:
fn[send] <: block
fn <: block
just as ~ and @ pointers can both be aliased using a reference.
Ironically, this is precisely what I proposed in my list of possible
solutions, but I did so using region terminology. Embarrassingly
obvious, in retrospect, particularly as that was Graydon’s original
design I believe. I think I got confused by the total ordering of
kinds into thinking that this should translate to a total ordering of
functions that close over data in those kinds. Anyhow, I will now
work on implementing unique closures in this partially ordered way,
and hopefully things will go more smoothly!
I have been trying to implement unique closures—or sendable functions, as I prefer to call them—but I realized that there is a fundamental problem that I hadn’t thought of before. The problem stems from two contradictory design goals:
The first requirement really demands that the sendable function’s environment be stored with a unique pointer. Otherwise multiple threads could share access to the same mutable state. Uncool.
The second requirement, however, demands that sendable functions should have the same representation as our other closure types—that is, they should be represented as the pair of a function pointer and a boxed environment.
Clearly something has to give. I see various options.
When sending a sendable function elsewhere, we could do a deep copy of the closure contents. However, we would want to allocate this copy in the target task’s heap. brson pointed out that there is a potential race condition of sorts, in that the target task might die before the message is constructed and sent. And in any case it just feels weird to have one task allocate in another task’s heap. The proper way to do this kind of thing is to use the exchange heap, as we do with unique pointers, but we can’t do that and preserve the subtyping relationship. There is also the fact that I think it should always be possible to send without copies, if you are willing to use unique pointers.
If fn[send] was not a subtype of fn, then a lot of our problems go
away. But if we down that route, then we end up with a lot of
different kinds of functions; we can no longer unify bare functions
and sendable functions, since bare functions must be usable as
closures. I have a personal goal of keeping the number of function
types to three or less, analogous with ~, @, and &.
This is basically what I half-proposed in
my previous post about procedures/coroutines. I like this
idea but it’s a bit of a departure from what we have; if we did it, I
would probably want to go “whole hog” and support coroutines, though I
think for 0.1 starting with one-shot procedures would be more
realistic. One thing I like about it is that we can reduce down to
two function types: fn(T)->U and block(T)->U. fn(T)->U would be
used for (what are today) bare functions and lambdas. block(T)->U
would be used for blocks and would also be compatible with fn(T)->U.
Using coroutines, we can get ourselves down to two function types.
But there is a way to get down to one. Currently, a function type is
actually a pair of the function pointer and the environment. Another
option would be to make a closure be a single pointer to the
environment, and then to embed the function pointer into the
environment. Thus the type for all closures would be fn(T)->U.
This would be a dynamically sized type and hence subject to
various limitations; in particular, it could only be referenced by
pointer. We could then use the type of the pointer to also encode the
bound:
~fn(T)->U can only close over sendable state.@fn(T)->U can close over task-local state.&fn(T)->U can close over arbitrary state.Furthermore, the borrowing and aliasing rules would naturally allow
~fn(T)->U and @fn(T)->U to be used as &fn(T)->U, but only for a
limited time, etc.
I personally think the system that results from this is easy to explain. However, it has some downsides:
In any case, the fact that it relies on proposals that have not been implemented and will not be implemented for 0.1 make it not a viable option.
The route I am currently looking into is much more conservative. We basically do not support unique closures or any other alternative for 0.1. Instead, we address the particular pain point that started this quest: generic bare functions. Right now, generic functions take implicit arguments called type descriptors, which are basically a form of reflection. These type descriptors are always local to a thread. I am going to see how difficult it is to make them global. This would allow generic bare functions to be bound to specific types but remain bare functions. (If we do decide to “monomorphize”, as is under discussion, then this becomes a non-issue, as type descriptors are no longer needed.)
Assuming we take the none of the above option, what about the next
version of Rust? Hard to say. Personally speaking, I find the first
two options to be non-starters for the reasons stated previously. The
third option (coroutines) seems good to me if we can make them fast
enough to use for iterators (which I think we can). The fourth option
(pointer type is bound) appeals to me as well because it brings us
down to one type of function (fn(T)->U) without any loss of
expressiveness. We would probably want to see what performance impact
it has and if there are ways to mitigate it. In any case, there is a
long road between here and the fourth option, since we have to
implement the NIC proposal and fully spec out and implement
region support. However, the third and fourth options are not
incompatible, so maybe we will see both someday.