XMem: Type-Safe, Transparent, Shared Memory for Cross-Runtime Communication and Coordination Michal Wegiel Chandra Krintz Computer Science Department Univ. of California, Santa Barbara fmwegiel,[email protected] Abstract guages]: Processors – Run-Time Environments, Memory Manage- Developers commonly build contemporary enterprise applications ment (Garbage Collection), Compilers, Optimization using type-safe, component-based platforms, such as J2EE, and ar- General Terms Design, Experimentation, Languages, Manage- chitect them to comprise multiple tiers, such as a web container, ment, Measurement, Performance application server, and database engine. Administrators increas- Keywords Interprocess Communication, Managed Runtimes, ingly execute each tier in its own managed runtime environment Shared Memory, Transparent, Type-Safe, Garbage Collection, Syn- (MRE) to improve reliability and to manage system complexity chronization, Class Loading, Parallel through the fault containment and modularity offered by isolated MRE instances. Such isolation, however, necessitates expensive 1. Introduction cross-tier communication based on protocols such as object se- Developers today predominately construct modern, enterprise, rialization and remote procedure calls. Administrators commonly component-based, middleware for portable, distributed applica- co-locate communicating MREs on a single host to reduce com- tions using type-safe, object-oriented languages, such as Java, munication overhead and to better exploit increasing numbers of which users execute within managed runtime environments (MREs). available processing cores. However, state-of-the-art MREs offer These MREs typically support garbage collection (GC), dynamic no support for more efficient communication between co-located class loading, incremental compilation, as well as high-level thread- MREs, while fast inter-process communication mechanisms, such ing and synchronization primitives, among other runtime services. as shared memory, are widely available as a standard operating sys- One popular example from this application domain is JBoss, an tem service on most modern platforms. application server that provides a complete implementation of the To address this growing need, we present the design and imple- J2EE [32] specification, and that is architected on top of the Java mentation of XMem – type-safe, transparent, shared memory sup- platform [34]. port for co-located MREs. XMem guarantees type-safety through A common architectural design pattern employed by adminis- coordinated, parallel, multi-process class loading and garbage col- trators of enterprise applications is multi-tier deployment that par- lection. To avoid introducing any level of indirection, XMem ma- titions the system into independent domains, typically run using nipulates virtual memory mapping. In addition, object sharing in separate MRE instances (OS processes). Such isolation enables XMem is fully transparent: shared objects are identical to local ob- fault containment and modularity as well as more aggressive spe- jects in terms of field access, synchronization, garbage collection, cializations in the MREs (e.g., using the best-performing compila- and method invocation, with the only difference being that shared- tion strategy or garbage collection system for a particular applica- to-private pointers are disallowed. XMem facilitates easy integra- tion, set of activities, or domain). J2EE-based applications typically tion and use by existing communication technologies and software comprise at least three tiers: a web container (front-end presenta- systems, such as RMI, JNDI, JDBC, serialization/XML, and net- tion layer), an application server (business logic), and a database work sockets. engine (back-end data source) [34, 8, 60]. We have implemented XMem in the open-source, production- Multi-tier decomposition, however, necessitates expensive inter- quality HotSpot Java Virtual Machine. Our experimental evalua- process communication (IPC) between MREs (isolated compo- tion, based on core communication technologies underlying J2EE, nents). Since most general-purpose servers (e.g., web, applica- as well as using open-source server applications, indicates that tion, database) are designed for online transaction processing, in XMem significantly improves throughput and response time by which many clients perform many short transactions simultane- avoiding the overheads imposed by object serialization and network ously, communication overhead can constitute a significant portion communication. of the observed, end-to-end response time (especially when multi- ple isolation units are involved). Categories and Subject Descriptors D.3.3 [Programming Lan- To reduce the overhead of MRE IPC, administrators commonly guages]: Language Constructs and Features – Dynamic Storage co-locate multiple tiers on a single machine. Co-location simpli- Management, Classes and Objects; D.3.4 [Programming Lan- fies administration and configuration, enables efficient use of local network communication for IPC, and makes better use of multi- Permission to make digital or hard copies of all or part of this work for personal or processor architectures through increased thread-level parallelism. classroom use is granted without fee provided that copies are not made or distributed Emerging multi- and many-core systems are likely to make MRE for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute co-location increasingly commonplace. to lists, requires prior specific permission and/or a fee. Cross-MRE IPC mechanisms cannot depend on co-location, PLDI'08, June 7–13, 2008, Tucson, Arizona, USA. however, since MREs may alternatively be distributed across differ- Copyright c 2008 ACM 978-1-59593-860-2/08/06. $5.00 ent cluster nodes or be migrated to achieve load balancing and more effective utilization of server resources, an increasingly important low virtual XMem MRE Virtual Address Space (VAS) high virtual operation in virtualizing systems today [44, 47, 57]. Thus, MRE addresses addresses IPC employs high-overhead implementations of standard commu- MRE App. LC !C SHM Shared App. MRE nication protocols, such as remote procedure calls and object seri- Heap Heap Meta #$%ects Stac" Stac" alization, regardless of the proximity of the communicating MREs. We introduce support for transparent and type-safe, cross-MRE communication and coordination, called XMem. XMem is an IPC mechanism that enables object sharing between MREs co-located on the same machine and communication via extant distributed XMem protocols when physically separated. XMem is transparent in that MRE VAS shared objects are the same as unshared objects (in terms of field access, synchronization, GC, and method invocation, among oth- ers), except that XMem disallows pointers from shared objects into MRE a&d XMem Co'located MRE a&d XMem MRE-private storage. To enable efficient object sharing, XMem App. !lo$al#p MREs App. !lo$al#p manipulates virtual memory mapping to avoid indirection, i.e., all hreads hread hreads hread object references in the system are direct. Moreover, existing com- munication technologies, e.g., those employed by J2EE or network Figure 1. Co-located XMem MREs, and their virtual address sockets, can use XMem without application modification. spaces (VAS), that are attached to a shared memory segment XMem guarantees type-safety by ensuring that the MREs em- (gray area). The shared region contains meta-data (SHM-Meta) ploy the same types for shared objects when the communication and shared objects and is mapped at the same virtual address in medium is shared memory. XMem is also compatible with core each MRE. The GlobalOp thread in each MRE performs infrequent MRE services such as GC, dynamic class loading, and thread syn- global operations that XMem synchronizes across attached MREs. chronization. XMem coordinates MREs through infrequent, syn- chronized global operations that include GC and class loading. In summary, we make the following contributions with this work: of all attached MREs. Figure 1 depicts an example instance of an XMem system. Two MREs attach to the same shared mem- Improved integration of MREs with the underlying system. ory segment (gray area of the VAS) to share objects. We refer to • XMem provides a new, efficient communication mechanism the VAS of each MRE that is not mapped to the shared memory while maintaining standard, portable interaction with the lower- segment (white area of the VAS) as MRE-private. XMem systems level layers of the software/hardware stack. share per-instance, non-static data only – static (per-class) data is Direct object sharing via isolated channels between co-located MRE-private since static fields typically record program-specific • MREs isolated as distinct OS processes that avoids the trade- or MRE-specific state. Sharing of such fields can violate both type offs inherent to previous approaches [17, 4] by enabling com- safety and inter-process resource isolation. munication without serialization and data copying. Since we map shared memory to the same virtual address in all MREs, objects within the shared memory have the same addresses Extensions to the MRE services and abstractions, including • in all MREs. To guarantee memory and type safety, we disallow parallel, cross-process class loading and garbage collection. pointers from shared objects to private objects via a write barrier XMem implements