> Every
> single reviewer I showed a "no cycles" variant of rust to told me
> it was unacceptable and they would walk away from a language that
> prohibited cycles in all cases. All of them. We tried limiting it
> within subsets of the type system rather than pervasively: it still
> irritated and confused everyone.
Interesting, are these versions online anywhere?
> - It doesn't do anything about fragmentation. Our longer-term plan for
> the gc involves moving to mostly-copying[1], which compacts pages
> other than the conservatively-scanned set. And is incremental.
True, in fact fragmentation might be as bad or worse as the dead objects living
on in GC.
> > However, it cannot support cycles (without destroying its advantages
> > over GC), so it is a good idea to statically prevent them to avoid leaks.
>
> We tried this; various strategies for it. Ownership cycles even just
> within subtrees of well-organized ownership trees are not a rare
> occurrence. They are a result both of normal patterns within common data
> structures, and normal levels of coupling between subsystems in large
> applictions. Especially web browsers.
How about, however, something like (hypotetically) rewriting the Linux kernel
in Rust? (with limited amounts of unsafe code)
The issue there is that a kernel needs to provide syscalls to multiple CPU
concurrently running threads which manipulate shared data structures like the
filesystem.
Having the filesystem structures be local to a single task would destroy
performance on things like filesystem-bound loads on 32-core servers, while
adding global GC would make it impossible to provide soft and hard real time
guarantees needed for embedded systems.
So using a MutexARC/RWARC global reference counting scheme with fine grained
locks like the Linux kernel in fact does (along with RCU, but let's ignore that
for now) seems the only option, but it's currently not safely possible in the
current Rust, due to the inability to nest those structures safely with
checking.
Now it's not totally clear whether full checking of reference cycles is indeed
viable, but it seems the only way to achieve that, and it seems bothersome that
one could not write a fast and safe real-time POSIX-implementing kernel in a
language that is pretty much the only mainstream language that can hope to do
so.
Even excluding kernels, it seems network servers running on multi-socket
machines and needing to concurrently mutate complex object graphs would have
similar issues.
Although for those real-time might not be so essential, so adding optional
concurrent global GC (like Java has) would be an alternative (but is also quite
a bit of work).
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
