On 7/12/13 5:48 PM, Robert O'Callahan wrote:
Does Option<JSManaged<>> compile down to a single machine word with no overhead for dereferencing?
The Rust compiler now implements optimizations to compile Option of a pointer down to a nullable pointer (although I would have to verify that it indeed works in this case).
I think in most cases there will be some overhead for dereferencing, due to the write barrier required by a generational/incremental GC. There is also a write barrier needed by Rust for ensuring soundness of mutation (see the "Imagine Never Hearing the Phrase 'Aliasable, Mutable' Again" blog post for details).
In the current design reads need a barrier too, something that I just realized -- I should probably talk this over with Niko and pick some approach to fixing it in the Rust compiler. (There are various approaches; probably the easiest one is something like a ReadPtr trait known to the compiler.)
In general the overhead for writes and borrows will probably be only a couple of instructions over a dereference operation. Reads should be unbarriered, although I think we need a little more design to make that happen in the current language.
Patrick _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
