On Fri, Dec 06, 2013 at 10:17:40AM -0800, Patrick Walton wrote:
> Wouldn't these data structures be instead traced by the JS GC? ISTM
> if you are putting roots in a data structure it is best to make the
> data structure itself traced.
This is not necessarily the case -- creating a new kind of GCThing is
rather hard, and wrapping in an object is heavyweight compared to
allocating a data structure on the stack. But thinking about this
more, I think that Rust offers some nice solutions here.
First off, SpiderMonkey has an AutoObjectVector (I think that's what
it's called) that is used to store an arbitrary # of references. I
haven't looked at how this is implemented, but I don't see how it
could build on the Rooted types, so I guess it's some separate
thing. If we can implement Rooted I imagine we can implement this.
The only case where Rooted is really workable is when you have a
statically known number of things to root (statically known for any
given stack frame, at least). A simple example would be a struct
with multiple fields:
struct Context {
a: RootedObject,
b: RootedObject
}
Of course it's probably possible to have the compiler permit
something like:
let mut x = Context { a: root(), b: root() }
even though the return value of `root()` is not being stored
directly into an lvalue, but another option would be to use
lifetimes:
struct Context<'a> {
a: &'a mut RootedObject,
b: &'a mut RootedObject,
}
let mut a = root();
let mut b = root();
let mut x = Context { a: &mut a, b: &mut b };
> I think it's important to have this be safe in an ironclad
> sense--this is one of the most fundamental pieces of the Servo
> project--and as a result the `'return` lifetime is the solution I
> favor right now.
I tend to agree that we need to get this right and safe. The fact that
return has multiple use cases is appealing. However, it's also worth
pointing out that once closures are also an ideal solution here,
perhaps with some Haskell-do-like sugar to reduce rightward drift. The
main problem is the fact that LLVM or the Rust compiler must
devirtualize.
Niko
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
