renaming project, halo -> ray (#95)

doc/reference-counting.md

@@ -1,6 +1,6 @@
 # Reference Counting
 
-In Halo, each object is assigned a globally unique object reference by the
+In Ray, each object is assigned a globally unique object reference by the
 scheduler (starting with 0 and incrementing upward). The objects are stored in
 object stores. In order to avoid running out of memory, the object stores must
 know when it is ok to deallocate an object. Since a worker on one node may have
@@ -11,7 +11,7 @@ information.
 ## Reference Counting
 
 Two approaches to reclaiming memory are garbage collection and reference
-counting. We choose to use a reference counting approach in Halo. There are a
+counting. We choose to use a reference counting approach in Ray. There are a
 couple of reasons for this. Reference counting allows us to reclaim memory as
 early as possible. It also avoids pausing the system for garbage collection. We
 also note that implementing reference counting at the cluster level plays nicely
@@ -77,13 +77,13 @@ because they must be passed into `AliasObjRefs` at some point).
 The following problem has not yet been resolved. In the following code, the
 result `x` will be garbage.
 ```python
-x = halo.pull(ra.zeros([10, 10], "float"))
+x = ray.pull(ra.zeros([10, 10], "float"))
 ```
 When `ra.zeros` is called, a worker will create an array of zeros and store
 it in an object store. An object reference to the output is returned. The call
-to `halo.pull` will not copy data from the object store process to the worker
+to `ray.pull` will not copy data from the object store process to the worker
 process, but will instead give the worker process a pointer to shared memory.
-After the `halo.pull` call completes, the object reference returned by
+After the `ray.pull` call completes, the object reference returned by
 `ra.zeros` will go out of scope, and the object it refers to will be
 deallocated from the object store. This will cause the memory that `x` points to
 to be garbage.