API for allocating objects whose size is unknown at compiletime

[mystor]

Right now, the only way to allocate is through the safe Gc::new() interface which allocates based on a generic type parameter. It would be nice to also have an unsafe Gc::alloc() interface or similar which allows allocating objects whose size isn't known at compile time.

[Manishearth]

I wonder if this is easily done without DST (dynamic sized types) being properly supported in rustc.

But yeah, Gc<Trait> would be nice.

/me mumbles something about becoming Java

[mystor]

I'm also thinking of just supporting a raw api like:

fn alloc(size: usize, trace: fn (*const u8), root: fn (*const u8), unroot: fn (*const u8), drop: fn (*mut u8)) -> RawGc {}

// -- or --

struct GcHandlers { /* The above methods */ }
fn alloc(size: usize, handler: GcHandlers) -> RawGc {}

or something like that, which allows you to construct a garbage collected pointer from raw data.

It would be pretty darned unsafe, but could be useful for some persistent data structures.

[Manishearth]

Hm, that could work. But I suspect that we support just enough DST to make Gc<Trait> work like Box<Trait> and use vtables for dispatch. Not sure.

[Manishearth]

(It might be as simple as just putting a ?Sized bound on all the Ts)

[mystor]

I'll try the ?Sized bounds later today. I think I also want to add that as an unsafe API as well. I have a use-case in mind where I'm going to have to interoperate with non-rust code with this API, and I need an API like that to do it, as non-rust code can't allocate right now.

[Manishearth]

I think we should focus on soundness first and try to break the GC with tests :) But adding bounds like this is easy enough so go ahead!

I had a closer look at the code/design, and while there are some things which could be improved (I'll comment later when I have the time or just fix directly), it looks sound to me. I think. Maybe. 😛

I also had a very illuminating talk with huon and aatch regarding stack scanning. I still think we should avoid it for this project, but perhaps it would be fun to design one of those GCs too once this is finished :)

[mystor]

Yeah. There are a lot of problems with stack scanning, especially if we decide to let people put garbage collected pointers inside of boxes (which means that the pointer isn't on the stack). I think our mechanisms are the least likely to be unsound, but we should do some more tests.

[andersk]

Rust is unable to convert [T] or even [u8] to dyn Trace, because fat pointer metadata has room for a vtable pointer or a length but not both (rust-lang/rust#61977). So we need a different representation than GcBox<dyn Trace> if we want this to be possible.