Checkpoints of GUI-based Applications Victor C. Zandy and Barton P. Miller Computer Sciences Department University of Wisconsin – Madison, USA {zandy,bart}@cs.wisc.edu Abstract tion’s GUI might migrate as the application itself migrates, or independently of the application. Both We describe a new system, called guievict, that enables the types of migration require the ability to capture the graphical user interface (GUI) of any application to be application’s window session, a transportable represen- transparently migrated to or replicated on another display tation of its GUI. Window sessions are difficult to cap- without premeditative steps such as re-linking the application ture because not all of the state they represent is resident program binary or re-directing the application process’s in the application. Portions of an application’s GUI state window system communication through a proxy. Guievict is reside in the window server, a separate system that han- based on a small X window server extension that enables an dles the display of all GUI-based applications on the application to retrieve its window session, a transportable representation of its GUI, from the window server and a library same host. Most window servers do not provide a way to of GUI migration functionality that is injected in the extract the state of an individual application’s resources. application process at run time. We discuss the underlying Guievict has been implemented for the X window technical issues: controlling and synchronizing the system [19] and has the following characteristics: communication between the application and the window ❏ Migration occurs at application granularity; users system, identifying and retrieving the GUI resources that form the window session, regenerating the window session in a new can select and move the GUI of individual applica- window system, and maintaining application transparency. We tions from their desktop, leaving other application have implemented guievict for the XFree86 implementation of GUIs behind or free to move elsewhere. the X window system. The GUI migration performance of ❏ Any application program, including those based on guievict is measurably but not perceptibly worse than that of a legacy toolkits, can be migrated without modifica- proxy-based system. tions such as re-programming, re-compiling, or re- linking. 1INTRODUCTION ❏ Migration can be unpremeditated; users do not need Application mobility is the ability for an application in to run their applications in a special way, such as by execution to follow its user, whether the user moves redirecting their GUI communication through a from one computer to another or moves with their com- proxy. puter around the Internet. This mobility includes mov- ❏ No modifications to window system code are ing the executing code, network connections, access to required; our functionality is contained in the win- the graphical user interface (GUI) or the GUI itself, and dow server extension, which does not require the access to files. We are developing a roaming applica- server to be re-linked, and a library that is loaded in tions system, called evict, that addresses these issues, the application at run-time. providing application mobility that is transparent to users and applications while requiring no modification ❏ The guievict functionality can also be used to repli- to system code. cate the GUI of individual applications on demand This paper describes guievict, the part of the evict on multiple desktop hosts, enabling multiple users system that migrates an application’s GUI. An applica- to interact with a single instance of an application for collaborative work or to support remote service. There are several essential elements to a GUI-based This work is supported in part by Department of Energy Grants application (see Figure 1). The application runs in one DE-FG02-93ER25176 and DE-FG02-01ER25510, Lawrence Livermore National Lab grant B504964, NSF grants CDA- or more processes on the execution host and the user 9623632 and EIA-9870684, and VERITAS Software. The U.S. interacts with it from a possibly different desktop host. Government is authorized to reproduce and distribute reprints The desktop comprises a display, keyboard, and mouse for Governmental purposes notwithstanding any copyright no- managed by a window system that multiplexes the desk- tation thereon. Before Initialization After Initialization Desktop Host Execution Host Execution Host Execution Host Window Application Server Application Application EvictLibrary GUI Libraries Communication X Libraries Channel X Libraries Display Keyboard Mouse User Evictor Figure 1: The elements of a GUI-based application. The user interacts with the application through hardware managed by the window server on the desktop Figure 2: Initializing the application process. host. The application process executes on a possibly The evictor stops the application process, forces it to different execution host, exchanging GUI-related load the evict client library, and exits. messages with the window server over a communication tion migration enables other useful operations, such as a channel. GUI attach that allows other users to dynamically attach top for all applications that interact with the user at that to and interact with the GUI of another user’s applica- host. The window system responds to requests for GUI tion. services (such as creating a window) sent by the applica- Guievict offers two major advantages over previous tion and passes notification of desktop events (such as a systems that perform GUI migration at application gran- mouse click) to the application over a communication ularity, most notably xmove [22]. First, it enables users channel such as a network connection or (when the exe- to migrate their applications without the premeditative cution and desktop hosts are the same) shared memory. step of redirecting the application to the xmove proxy. The state of the application GUI is distributed between Although the details of the redirection can be hidden the window system and a library (often called a toolkit) from the user in a launch script, the user still must use in the application process. the script to start applications that they anticipate mov- Our focus is on the migration of a single application ing. In contrast, guievict offers application mobility fea- from one desktop host to another. Our abstraction tures without asking users to develop new habits and encapsulates precisely the GUI state of the application foresight. Second, it simplifies process migration of — not individual windows of the application, nor the GUI-based applications. Although migration was not windows of all applications that are being served for the one of its original design goals, xmove can be combined user on the desktop host. Many previous systems have with process checkpointing to migrate a GUI-based studied techniques for session migration, in which a application. However, in addition to the application pro- user’s entire desktop is migrated to another cess, the xmove proxy and the state of the communica- machine [7,14,16,17,23]. Our ability to migrate at appli- tion channel between the proxy and the application must cation granularity has several advantages over session be checkpointed and migrated. With guievict, the win- migration. First, it is flexible: it gives users the freedom dow session and mechanisms that manage its migration to migrate only the applications they need at their new reside in the address space of the application process, location, saving migration costs, and it enables users to where it can be migrated along with application code work with multiple desktops at the same time. Second, and data. session migration systems generally involve a virtualiza- To migrate the GUIs of ordinary, unmodified appli- tion layer, such as a virtual machine [7,14] or nested cations from one display host to another, we have over- window server [16,17], a sort of GUI prison to which come four main challenges: the user must redirect their applications in advance. In ❏ Dynamically taking control of the window system addition to the inherent overhead of virtualization, these communication of a running program: We inject layers often emulate basic and generic display hardware, code into the application process that discovers the preventing applications from taking advantage of process’s communication channel to the window enhancements or acceleration features present in the real server and synchronizes its communication with the underlying hardware. Third, a mechanism for applica- server. Before Detach After Detach Execution Host Desktop Host A Execution Host Desktop Host A Window Application Window Application Server Server EvictLibrary EvictLibrary Evict Evict Window Extension Extension Session ➊Retrieve Window Session X Libraries X Libraries ➋ Window Session Desktop Host B Desktop Host B Window Window Server Server Evict Evict Extension Extension Window system socket connection Guievict message Figure 3: Detaching a GUI from Desktop A. The evict client library requests the window session from the evict server extension at Desktop A, then closes connection. ❏ Retrieving the GUI resources of an application: We issues raised by guievict. Section 6 presents related have developed an extension to the X window work. server that enables an application, at any time, to determine the identifiers of its GUI resources and 2SYSTEM OVERVIEW the dependencies among these resources, and to The major steps in the operation of guievict are: initial- extract these resources in a form from which they izing the system, migrating an application’s GUI from can be regenerated on a new desktop. one desktop host to another, replicating an application’s ❏ Regenerating an application’s resources in another GUI on multiple desktops, and migrating an application desktop host: We use standard X protocol opera- process along with its GUI. These operations involve tions to regenerate GUI resources in the new win- four system components. The evictor is a program that dow server. the user runs to control the evict system. The user runs it ❏ Ensuring GUI migration is transparent to the appli- on the same host as the application process.