outstanding uses of ->malloc in src/rt

gistfile1.txt

jeff@mbp:~/src/rust/build$ find ../src/rt/ -name '*.cpp' -exec grep '.->malloc' -H -n {} \;
../src/rt/rust_builtin.cpp:98:    rust_rng *rng = (rust_rng *) task->malloc(sizeof(rust_rng),
../src/rt/rust_stack.cpp:61:    stk_seg *stk = (stk_seg *)region->malloc(total_sz, "stack");
../src/rt/rust_stack.cpp:78:    stk_seg *stk = (stk_seg *)exchange->malloc(total_sz);
../src/rt/rust_uv.cpp:40:  void* ptr = rust_get_current_task()->kernel->malloc(size, tag);
../src/rt/boxed_region.cpp:22:      (rust_opaque_box*)backing_region->malloc(total_size, "@");

Since task is still implemented in C++ I don't think we can completely remove the C++ local heap. task->malloc and boxed_region are both related to the local heap, so I don't think we should touch yet.

The rust_stack allocations are trickier. Rust stack segments are allocated on the local heap, so those are fine for now, but native stack segments are allocated on the exchange heap. Ultimately, I would like both to be allocated on the exchange heap and cached in the same pool inside the scheduler. Eventually these will both be rewritten in Rust and will have access to the exchange heap.

The uv code though I don't think we'll ever rewrite in Rust because of the issue of maintaining struct definitions.

So we have two allocations that can't be allocated in the local heap and need to be written in C++. I'm inclined to change exchange->malloc and kernel->malloc to just malloc. Some of the work I've done on the new scheduler is also just calling malloc directly, and I'm trying to convince myself that this is ok, that not every byte needs to go through Rust's allocator (which after all is just malloc anyway). When you need to allocate something that isn't a Rust type, malloc is fine, right?