Vectors are now similar to our old, pre-internal vectors, except that
they are uniquely owned, not refcounted.
Their name should probably change too, then. I've renamed them to vec
in the runtime, will do so throughout the compiler later.
rust_start will always call _rust_main with the command line args, and it is
_rust_main's responsibility to free the args ivec heap. _rust_main will be
generated slightly differently depending on whether main takes an ivec or not:
if so then it's just passed through to main, otherwise it frees the ivec
directly.
This is the new way to refer to tasks in rust-land. Currently all they
do is serve as a key to look up the old rust_task structure. Ideally
they won't be ref counted, but baby steps.
getenv is not threadsafe and (maybe as a result) it's randomly crashing with
CFLAGS=-g and RUST_THREADS=32. Calls from rust code are still on their
own.
Tasks are spawned on a random thread. Currently they stay there, but
we should add task migration and load balancing in the future. This
should drammatically improve our task performance benchmarks.
We're trying to get closer to doing correct move semantics for channel
operations. This involves a lot of cleanup (such as removing the
unused sched parameter from rust_vec constructor) and making
circular_buffer kernel_owned.
Added tagging for memory allocations. This means we give a string tag
to everything we allocate. If we leak something and TRACK_ALLOCATIONS
is enabled, then it's much easier now to tell exactly what is leaking.
See https://github.com/graydon/rust/wiki/Logging-vision
The runtime logging categories are now treated in the same way as
modules in compiled code. Each domain now has a log_lvl that can be
used to restrict the logging from that domain (will be used to allow
logging to be restricted to a single domain).
Features dropped (can be brought back to life if there is interest):
- Logger indentation
- Multiple categories per log statement
- I possibly broke some of the color code -- it confuses me