Jeffrey Bosboom's Blog

[blog] [projects] [about]

Hop

While an undergraduate at the University of California, Irvine, I worked under Professor Michael Dillencourt on the Hop system, which implements thread migration for Java programs via bytecode transformation.

When porting an existing program running on a single node to a cluster (to take advantage of more compute or memory resources), programmers must either pay the high cost of distributed shared memory or restructure their program to use message passing. Thread migration offers a porting path compatible with existing imperative code: the programmer calls a function hop(targetMachine), and when it returns, the thread is executing on the specified machine. Porting a program to leverage additional memory on other machines requires only adding a dictionary mapping data records to machines; essentially, computation moves to the data rather than the other way around. Threads synchronize with the standard primitives (synchronized, ReentrantLock, BlockingQueue etc) after migrating to a common machine.

The Hop system is a proof-of-concept implementation that migrates only the current stack frame, creating a two-dimensional call stack, where the vertical dimension is the traditional stack and the horizontal dimension represents migrations between machines. Hop migrates the local variables of the current stack frame and all objects reachable from them and restores them when returning from migration. This results in objects having different identity; if some other thread had a reference to a migrated object, its reference will not be updated to point to the new object. Additionally, Hop does not provide facilities for controlling what state is migrated, so careless use can migrate all objects in the virtual machine. These issues somewhat limit Hop’s usefulness for porting single-node applications to clusters.

The Hop sources are available for download. The code is licensed under GPLv3+. I only worked on Hop during a ten-week quarter of independent study, so the code is not production quality. The project follows on from Dillencourt’s MESSENGERS project and there is other related work on thread migration, including Java implementations, in the literature.