GoA: Actors with Locally Managed Memory for Go

Reasoning about concurrent programs and the way they manage memory can be difficult. Single-process programs can allocate memory without concern regarding data races or memory corruption, but multi-threaded programs must have a system in place to ensure safe memory allocation. Typically, threads and processes use a system of locks or mutexes that are explicitly managed by the user. These locks allow safe access to shared data. Languages that use Actors as a concurrency construct attempt to solve the problem without explicit locks. Actors use a system of message passing to ensure data is being shared correctly among processes. However, this message passing system requires all data to be shared by copying the data, not by reference. If references to data are to be shared safely, another safety mechanism is needed. This thesis discusses a way to bring the actor paradigm to an existing highly concurrent language, Go. The project, named GoA, is an actor-based library for Go. GoA provides actor-local memory management, and a custom system to ensure data is shared safely among actors. GoA comes with a custom memory-management library that replaces all of Go's existing allocation, garbage collection, and message passing techniques. These new methods derive from the open source language Pony, a language with a memory management system called ORCA. Inspiration is drawn from ORCA to integrate similar techniques into GoA. The custom memory manager aims to alleviate the overhead of Go's global garbage collection and allow actors to manage themselves so they do not slow down or interrupt other working actors. A memory safety system is also introduced that provides a way for all memory usage across all actors to remain safe from races and corruption. Using ideas from Pony, a capability system that annotates allocated objects with specific rules that apply when sharing data is constructed. This system allows for local objects and sharable objects. Local objects are not allowed to leave the scope of the owning actor. Shareable objects must be annotated with one of the following three capabilities: mutable, immutable, or opaque. Mutable data is free to be manipulated, immutable data can only be read, and opaque data can neither be read nor overwritten. Each of these capabilities serve their specific purposes and when declared on an object and used incorrectly, a runtime error is thrown to the user. A runtime checker system is used to check if every read and write on a variable is safe, and will handle any resulting errors Experiments and results indicate the local memory manager successfully speeds up the overall performance of the language. The basic speed benchmarks indicate the new library is slower than Go at allocating small objects, but significantly faster for allocating large objects. The N-Body garbage creation simulation showcases how GoA and its locally managed memory allows important actors to work without interference from other actors with large allocation needs, speeding up the effectiveness of the system