Jupiter: A Modular and Extensible JVM

Transcription

1 Jupiter: A Modular and Extensible JVM Patrick Doyle and Tarek Abdelrahman Edward S. Rogers, Sr. Department of Electrical and Computer Engineering University of Toronto {doylep tsa}@eecg.toronto.edu

2 Outline Motivation. Jupiter design. Configuration example (object allocator). Flexibility. Performance. Status of the implementation. Conclusions and future work. Doyle & Abdelrahman 2

3 Research into Scalable JVMs Research goal: to investigate JVM architectures to deliver high performance on large-scale parallel systems. 128-processor cluster of workstations with software-based SVM. Single system image (SSI). Research on Java-based SSI on clusters to date is limited to small numbers of processors. cjvm Jessica Hyperion etc. It remains unclear how to design a JVM to scale well to large numbers of processors. Doyle & Abdelrahman 3

4 Approaches to Scalability Four main target areas: Memory locality. Garbage collection. Memory consistency. Support for threading and synchronization. We will investigate alternative approaches in each area. Doyle & Abdelrahman 4

5 JVM Infrastructures In order to carry out this research, we need a JVM infrastructure that is: Modular. Flexible/Extensible. Efficient. Currently available JVMs: Hard to modify (Kaffe or Sun JVM). Designed to address a specific aspect of JVM performance. Hence, we elected to build our own infrastructure. Hard. Rewarding. Doyle & Abdelrahman 5

6 Jupiter Philosophy Jupiter is assembled out of small modules. Much like UNIX pipelines. Interconnection of modules determines JVM behavior. Module requirements: Atomicity: modifications should not split modules. Cohesion: modifications should involve few modules. Independence: unrelated modifications should be orthogonal. Must find a balance. Two kinds of modules Facilities: manage resources. Resources: used by a running Java program (e.g. Classes, Objects, Threads, etc.). Doyle & Abdelrahman 6

7 Jupiter Overview Memory Allocator ClassSource MemorySource Class Class Memory Memory Object Object ExecutionEngine Lock Lock Thread Thread Native Native ThreadSource NativeSource Thread Library Native Libraries Doyle & Abdelrahman 7

8 An Incarnation of Jupiter ExecutionEngine ThreadSource ClassSource NativeSource Native Libraries Thread Library MemorySource Class Loader Memory Allocator Module instance Uses relation Doyle & Abdelrahman 8

9 Object Allocator Example ExecutionEngine MemorySource Extend to achieve locality: void *nodealloc(int nodenumber, int size); Multiple levels: Memory allocation level. Object allocation level. Execution engine level. alloc() Doyle & Abdelrahman 9

10 Node-specific MemorySources ExecutionEngine MuxMemorySource MemorySource_1 MemorySource_N nodealloc(1, ) nodealloc(n, ) MemorySource for each node. Same MemorySource interface. Minimal change to the implementation of MemorySource. Locality decisions made transparently in MuxMemorySource. Doyle & Abdelrahman 10

11 Node-Specific s ExecutionEngine Mux MemorySource_1 MemorySource_N nodealloc(1, ) nodealloc(n, ) for each node. Enhances locality without altering interface. Node choices still transparent to ExecutionEngine. Same,, MemorySource_i as before. Doyle & Abdelrahman 11

12 A Locality-Aware ExecutionEngine ExecutionEngine MemorySource_1 MemorySource_N nodealloc(1, ) nodealloc(n, ) Locality-aware ExecutionEngine. ExecutionEngine directly manages locality. Same,, MemorySource_i as before. Modifications confined to ExecutionEngine. Doyle & Abdelrahman 12

13 Combined Appraoch ExecutionEngine Mux MuxMemorySource MuxMemorySource MemorySource_1 MemorySource_N MemorySource_1 MemorySource_N nodealloc(1, ) nodealloc(n, ) nodealloc(1, ) nodealloc(n, ) Modifications confined to a small number of modules. Multiple configurations through module interconnections. Doyle & Abdelrahman 13

14 Performance ExecutionEngine ExecutionEngine MemorySource_1 MuxMemorySource MemorySource_N nodealloc(i, ) nodealloc(1, ) nodealloc(n, ) Two problems: Call overhead: must make calls through the module hierarchy. Object proliferation: MemorySource_i for each node i. Doyle & Abdelrahman 14

15 Performance Standard MemorySource declarations: typedef struct ms_struct *MemorySource; void *ms_getmemory(memorysource this, int size); MemorySource constructors: MemorySource ms_new(int nodenumber); MemorySource ms_newmux(); MemorySource usage: void *ptr = ms_getmemory(obs_memorysource(), size); Doyle & Abdelrahman 15

16 Performance Custom declarations for nodealloc: typedef int MemorySource; inline MemorySource ms_new(int nodenumber){ return nodenumber; } inline MemorySource ms_newmux(){ return 1; } inline void *ms_getmemory(memorysource this, int size){ if(this == ms_newmux()) return nodealloc(/* Some node */, size); else return nodealloc(this, size); } Doyle & Abdelrahman 16

17 Performance void *ptr = ms_getmemory(obs_memorysource(), size); void *ptr = ms_getmemory(ms_newmux(), size); void *ptr = ms_getmemory(-1, size); void *ptr = nodealloc(/* Some node */, size); Doyle & Abdelrahman 17

18 JIT Compiler ExecutionEngine IR Native JIT OpcodeSpec Interpreter mode JIT mode Frame Interpreting Base Classes Frame Object Object Code-generating Base Classes Use OpcodeSpec module that is always executed by the ExecutionEngine. OpcodeSpec functions: Interpret bytecode, or Emit IR, which is passed to the JIT compiler. Doyle & Abdelrahman 18

19 Status Project started in March Core JVM implemented in C: All single-threaded facilities and resources. Interpreter-based execution engine. Native interface: java-to-native calls, but no callbacks. Can execute simple programs. Performance poor compared to Kaffe and Sun, mostly due to implementation problems. Doyle & Abdelrahman 19

20 Conclusions and Future Work We presented a JVM structure designed to be modular, flexible and efficient. Instances of well-defined modules. Interconnection of modules. Performance. The project is in its early stages, and future work will focus on completing the implementation. Research goals. Doyle & Abdelrahman 20