Memory Management in the Emu Migratory Threads Model

Emu Migratory Memory Side Processing supports a single distributed shared memory address space, which encompasses the memory in all nodes. Each node includes our own specialized lightweight cores for executing migratory threads. We call them Gossamer Cores, reflecting the ultra-lightweight nature of the architecture. Each node also includes a Stationary Core, a conventional CPU that is used to run the operating system, which allows maximum use of existing system software and tools. An instance of Linux runs on all Stationary Cores. The Stationary Core has preloaded copies of needed migratory threadlet code to all nodes’ Gossamer Cores where it may be executed. A user process runs on the Stationary Cores but schedules most computational work on Gossamer Cores. Stationary Cores handle service requests from the threadlets running on the Gossamer Cores, including memory allocation and release, I/O, exception handling and performance monitoring.

Thread states are explicitly separated from process state, and made very light. Whenever the application either wishes to access off-node memory or start a threadlet-supported computation, it creates a threadlet state and launches it. This threadlet may then perform additional spawns to start arbitrary additional operations in parallel. Each node is made of multiple nodelets. Gossamer Cores support the automatic migration of execution threads whenever they attempt to read from a memory address that is not contained in the current nodelet. When a non-local address is detected, the Gossamer Core suspends the thread and sends its thread state to the nodelet holding the desired address. At this nodelet, the thread state is placed in any available GC and restarted. Thus, all memory references by a thread are always performed “locally.”


Question posed by Fidelity Investment Director of System Engineering. “How do the stationary cores know to which gossamer core to send the processing?”