I'm intrigued by the 3 level memory system (stack, ref count, gc) and wonder how that works out in practice. Does it ever get in the way?
I'm also a bit curious about ref counting. As a memory management technique it is known to be slower than a good GC, partly because of the overhead of managing the count, and partly because doing so can destroy cache coherence by touching memory that otherwise doesn't need to be touched. Also, at least in C++ the primary use of destructors is to release memory which is not necessary with a GC, and ordered and timely release of memory is not really useful except perhaps in application with hard real time constraints. On the other hand, ordered synchronous release of some resources (file handles, locks, etc) is essential, but many languages without destructors (such as Ocaml) don't seem to have a huge problem with this. Also, destructors have a very serious design fault: faults in destructors are notoriously hard to handle. So I'm curious about the decision to use ref counting and deterministic destructors. [I'm just curious, I think the design is very interesting!] FWIW, I also had this 3 level system implemented in my language Felix, but without the explicit static control Rust provides. What I found was that the performance overheads, especially in the presence of shared memory concurrency that Felix supported, were very high. Stuff ran a lot faster when I threw it out. I should say that in Felix, ref counting didn't exclude cycles so the GC had to scan the whole heap, ref counted or not: the load was only reduced when the ref counts removed memory prior to a GC phase. Does Rust ensure ref counted objects can't contain cycles? Anyhow, the Rust system seems very promising to me! -- john skaller [email protected] _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
