4 ms·

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 dereferencin

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.

burntsushi 9y ago
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.
- rbehrends 9y ago
  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.
  - burntsushi 9y ago
    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.
    - rbehrends 9y ago
      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.

burntsushi 9y ago

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.

rbehrends 9y ago
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.
- burntsushi 9y ago
  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.
  - rbehrends 9y ago
    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.