Hacker News Reader

Comment by adwhit | Hacker News Reader

You might be interested in this paper [0] wherein the authors implement a high-performance GC in Rust. Quoting the abstract:

We find that Rust’s safety features do not create significant barriers to implementing a high performance collector. Though memory managers are usually considered low-level, our high performance implementation relies on very little unsafe code, with the vast majority of the implementation benefiting from Rust’s safety. We see our experience as a compelling proof-of-concept of Rust as an implementation language for high performance garbage collection.

[0] http://users.cecs.anu.edu.au/%7Esteveb/downloads/pdf/rust-is...

View on HN

That seems to be a bit misleading. What they seem to do, inter alia, is expose memory addresses as a safe type in Rust, with pointer arithmetic and dereferencing simply declared safe without it actually being so. There is no check that the underlying address actually points to valid memory, satisfies aliasing rules, etc.

Did you read the paper? Dereferencing is not "simply declared safe." There's an entire section of the paper that goes over the API of the Address type, and explicitly points out that dereferencing is considered unsafe. Their conclusion runs directly contrary to your stated claims:

> We found that the Rust programming model is quite restrictive, but not needlessly so. In practice we were able to use Rust to implement Immix. We found that the vast majority of the collector could be implemented naturally, without difficulty, and without violating Rust’s restrictive static safety guarantees. In this paper we have discussed each of the cases where we ran into difficulties and how we overcame those challenges. Our experience was very positive: we enjoyed programming in Rust, we found its restrictive programming model helpful in the context of a garbage collector implementation, we appreciated access to its standard libraries (something missing when using a restricted language such as restricted Java), and we found that it was not difficult to achieve excellent performance. Our experience leads us to the view that Rust is very well suited to garbage collection implementation.

Oops, I meant to write pointer conversion, not dereferencing. Yes, I read the paper, as I was taking that directly from the Rust code shown in the paper.

The underlying problem is that Rust's borrow checker cannot possibly capture at compile time the arbitrary relations between objects managed by a garbage collector and arbitrary object layouts. Whatever guarantees it provides, memory safety isn't one of them (and cannot be), even if nominally only part of it is unsafe code. Pointer arithmetic and memory safety do not mix.

What you get out of that is basically an alternative approach to information hiding, not memory safety.

It sounds like you're shifting the goal posts pretty dramatically to me. Compare what you said above (which presumably prompted the reference to this paper)

> Writing a garbage collector runtime in Rust has most of the same problems in Rust as in C, because you have to write most of it in unsafe code, where Rust inherits much of C's undefined behavior w.r.t. pointers via LLVM. In short, you have largely the same problems and have added a hard dependency on Rust.

to the conclusions drawn in the cited paper. They sit in pretty stark contrast from where I'm standing.

I'm not sure where you're getting the "goal post shifting" from. Writing "p.plus(n)" in their Rust code is not materially different from what "p + n" would be in C/C++ code. That the former is nominally safe code doesn't change the fact that the same unsafe Rust code gets inlined at every callsite. You could do the same in C++ by creating an Address class (similar to smart pointers) with restricted operations; these operations would not magically become safer just because they're inlined by the compiler rather than spelled out in the code.

Reply on news.ycombinator.com