On Wed, May 22, 2013 at 7:39 AM, Zoltán Tóth <[email protected]> wrote: > Hi Folks! > > I am new on this list. I am a regular C++ algorithm programmer, who is very > interested in Rust. > > First of all - congratulation for this project. > > > After reading the tutorial (which btw I found very good quality (it is both > concise and explanatory in the same time)), I still have questions about the > project. I also quickly went throught the manual, but neither it did answer > my questions. I hope you will and I ask you too extend the documentation > with the answers. > > > 1) The implementation details of the garbage collector. I understand that > implementation details may sound a bit boring topic for a languge designer, > but for anyone considering using the language in practice it may be a > decisive factor. > > Abou the GC: > Is it precise? It is moving? Is it based on clang? When is gc triggered? > Does it call the destructors of objects detected as garbage?
There's not currently a working garbage collection implementation beyond reference counting and an annihilator to destroy cycles at the end of a task. The garbage collector will be task-local since managed boxes are task-local, and it can eventually be a nice precise, generational, compacting collector. Mutable managed boxes already have to keep of whether they are borrowed from, so the data needed for a moving collector is already there for @mut. > About the exchange heap: > Is it compacted? It uses the allocator from the system's C standard library. In the future, Rust will probably ship with an allocator like jemalloc/tcmalloc for consistent performance across platforms but they aren't much different than glibc's standard allocator. Small allocations are allocated in groups by size, so the heap is already compact. Large allocations don't go through the thread-local caches. > The importance of these questions is from the fact that Rust denies explicit > memory management for the programmer and instead forces its own solutions, > the GC heap and the exchange heap. It doesn't deny anything, there are examples of alternate memory management solutions in the standard library (std::rc, std::arc, std::arena). Unique pointers/vectors are a thin wrapper around malloc/free. > 2) Rust does not provide exception handling, but in the same time still does > stack unwind. I can understand choices either for or against EH in a new > language, but this mixture seems weird. I missed a design rational about > this decision. Why is the task fail ability so important that it is worth > the inclusion of stack unwinding into a semantics that does not support EH > anyway? Or do you consider stack unwind a cheap, non-problematic addition? > If you omitted stack unwind, then the user programmer could always easily > argue about the execution flow of its code easily, which is a big advantage. > Now the user does not have EH, but still has its disadvantage, that is - has > to worry about exception safety (RAII takes care of only the majority of > exception safety issues, not all, right?). Task failure is exception handling with the restriction that you can only catch them at task boundaries. Since tasks don't share memory, there are few of the usual exception-safety concerns like implementing any series of mutations in a transaction. > How is unsuccessful memory allocation handled? It's handled by exiting. Handling it by unwinding like C++ isn't possible because growable stacks result in almost anything being a potential allocation. Although, unsuccessful memory allocation doesn't actually occur on a system using overcommit. Resource exhaustion happens during a page fault. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
