4 ms·
Rust itself can't, but you as the programmer can. It's not quite C, but you can do a lot of reasoning about what the compiler will do with your code, and avoid
by qwertyuiop924 10y ago
Rust itself can't, but you as the programmer can.
It's not quite C, but you can do a lot of reasoning about what the compiler will do with your code, and avoid pathological cases.
- naasking 10y agoAbsolutely, you have to be aware of the ownership graph depth in both C and Rust if you want to bound latency. You don't have to do this with tracing GC though, you just need a runtime that implements latency bounds.
- qwertyuiop924 10y agoWait, why would you have to do that? Most ownership is determininstically resolved at compile time, so you can know exactly when a resource will be freed. What you do have to know is about the rare refcounted variable, and what edge cases require ownership checking at runtime.
- naasking 10y agoThe latency problem isn't caused by determining what to free, the latency problem is caused by actually freeing. Imagine an array with 2^31 pointers, and now fill it with with 2^31 distinct pointers to the remainder of the 2^32 bit address space. When that array goes out of scope, you can now enjoy 2^31 individual free operations, because reclamation for Rust lifetimes and reference counting are both proportional to the number of dead objects (copying collection takes zero time in this case). If bounded latency is a goal, you have to bound the depth of of your ownership graph if you're working on a platform that doesn't impose global latency properties. C/C++ and Rust do not do this.
- pcwalton 10y agoThis is only true for pure two-space copying collectors, which are rarely used in practice because of the absurd memory overhead. Once you introduce mark/sweep for some portion of the heap (like production GCs do), you reintroduce overhead proportional to the number of dead objects during the sweep phase.
- qwertyuiop924 10y agoAh. But C has this problem as well. If you've malloc(3)ed an array of 2^31 pointers, each pointing to an object, enjoy your 2^31 free(3)s, or prepare to start leaking RAM. So what's your point?
- naasking 10y agoYes, C/C++ and Rust have the same problems, as I said elsewhere. My ultimate point is that low latency is a property of a runtime, not a language. Using C/C++ or Rust aren't going to automatically give you bounded latency, and adding tracing GC doesn't automatically take it away.
- qwertyuiop924 10y agoOh. Well then actually, we're in complete agreement. Sorry.
- solidsnack9000 10y agoThe language and runtime typically cooperate to provide the operational semantics that developers are looking for. The case of Objective-C is especially interesting in this regard: developers evolved a number of conventions around reference counting, because reference counting allowed for controllable, minimal latency and contributed to a snappy UI. The language gradually absorbed these conventions into the compiler, such that certain patterns of use are part of the language specification (certain method names, basically) and the ARC code is generated for developers.
- foota 10y agoI believe their point is that an object can own potentially many objects, and when it is dropped it could cause a cascade of dropping. Which may not be expected by someone.
- kazagistar 10y agoWell, the good news for you then is that there is progress underway to implement Gc-as-a-library in Rust, to give you this option if you need it as well.