---

yaml
---
r: 22650
b: refs/heads/master
c: 019a41b
h: refs/heads/master
v: v3

Author: lkuper

[refs]

@@ -1,5 +1,5 @@
 ---
-refs/heads/master: d9cbdf78656def0290e53353539681db612ecf1f
+refs/heads/master: 019a41bdb09c612e42717df2ae2148a29361842f
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: cd6f24f9d14ac90d167386a56e7a6ac1f0318195
 refs/heads/try: ffbe0e0e00374358b789b0037bcb3a577cd218be

trunk/doc/tutorial.md

@@ -1197,15 +1197,14 @@ Rust has three competing goals that inform its view of memory:
 
 ## How performance considerations influence the memory model
 
-Many languages that offer the kinds of memory safety guarantees that
-Rust does have a single allocation strategy: objects live on the heap,
-live for as long as they are needed, and are periodically
-garbage-collected. This approach is straightforward both in concept
-and in implementation, but has significant costs. Languages that take
-this approach tend to aggressively pursue ways to ameliorate
-allocation costs (think the Java Virtual Machine). Rust supports this
-strategy with _shared boxes_: memory allocated on the heap that may be
-referred to (shared) by multiple variables.
+Most languages that offer strong memory safety guarantees rely upon a
+garbage-collected heap to manage all of the objects. This approach is
+straightforward both in concept and in implementation, but has
+significant costs. Languages that take this approach tend to
+aggressively pursue ways to ameliorate allocation costs (think the
+Java Virtual Machine). Rust supports this strategy with _shared
+boxes_: memory allocated on the heap that may be referred to (shared)
+by multiple variables.
 
 By comparison, languages like C++ offer very precise control over
 where objects are allocated. In particular, it is common to put them