Scaling J2EE™ Application Servers with the Multi-Tasking Virtual Machine

1. Scaling J2EE™ Application Servers withthe Multi-Tasking Virtual Machine Razieh Asadi University of Science and Tecnology Mazandran Babol

2. What is Java 2 Platform, Enterprise Edition (J2EE) ? • Standard Server-side environment for developing enterprise application and realizing Application Server • Provide functionality for distributed and multi-tier application, based on largely modular components running on an application server • Deploy on JVM and independent from operating system and hardware • Provide an operating environment

3. Provide an operating environment • execution multiple concurrent application • Classloader mechanism of Java platform for isolation • Threading mechanism for concurrent • Lower quality than Process model of an traditional operating system

4. - Limitation of operating environment compare to proccess model • No robust way to terminate Java application as threads Can not terminate threads safely • Degree of isolation provide by classloader model is weak compared to process operating system • No way to control important resources such as CPU time It is not possible to control resources, e.g. Amountof memory and CPU usage.

5. - J2EE server host a single application Single machine • Wasteful of memory (more processes) • System administration made more complex Several machine • Expensive and inefficient in terms of hardware.

6. Isolates and the Multi-tasking VM • extensible framework (API) for resource management is able to handle efficiently traditional resources: – CPU time, Memory, Network, Programmed-defined resources (e.g. JDBC connections) • This API introduces the concept of isolates: a fundamental unit of accounting.

7. Isolates and the Multi-tasking VM • An isolate is a Java application component that does not share any objects with other isolates. • The Isolate API allows for the dynamic creation and destruction of isolates. • new Isolate(“MyClass”, new String[ ] {“abc”}).start(); • Isolates does not share objects, but they can communicate using traditional inter-process communication: sockets and files.

8. Isolates and the Multi-tasking VM • Isolate API is fully compatible with existing applications. (There is no need to modify app unaware of the API) • One implementation is for all isolates to reside in a single instance of the JVM (called MVM)

9. Classloaders and isolates Isolation and termination guarantees of Isolates are much stronger • Termination • Isolates can not share object, terminated and unloaded cleanly • Isolation • isolation provide by Classloaders is incomplete • Complexity Classloaders add complexity

10. Multi-tasking Virtual Machine (MVM) • General-purpose virtual machine for executing multiple applications written in the Java language • MVM transparently shares significant portions of the virtual machine among isolates. For example:– Run-time representations of all loaded classes and compiled code are shared. • In effect, each application “believes” it executes in its own private JVM. • Certain JRE classes had to be modified (System and Runtime) to make some operations apply only on the calling isolate (example:System.exit()).

11. MVM architecture request Jlogin

12. MVM architecture • Operation of the MVM • Mserver: first isolate application that listens on a socket • Jlogin(a program written in C): connects to Mserver to run isolate for application • Mserver creates a new isolate according to the obtained request • Links: for efficient communication between Isolates

13. J2EE on MVM J2EE specification defines 4 application components types (Applets, EJB, Application Client, Servlet and JSP) an array of services (e.g., JMS and JDBC)that hosted in containers

14. J2EE on MVM • The containers are themselves hosted in servers, e.g., Web Server. • Replacing an entire JVM with isolate • Running multiple J2EE sever instances in MVM

15. Experiments for server startup footprint • MVM demonstrates improved scalability over HSVM • No significant difference for one server. • A reduction of 31% for 2 servers, and 43% for 3 servers. • MVM sharing class metadata mechanisms is proportionally more effective. • Metadata: bytecodes of methods,compiled bytecodes, other memory. • VM code: the only portion that can be shared by the OS (but is small).

16. Experiments for server deployed footprint Third Cloudscape instance MVM has a 20% smaller than footprint Third J2EE server instance startup has a 46% smaller than footprint In deployment phase Reduction drops back , similar for HSVM and MVM MVM is not able to share the classes that are loaded in separate classloaders. In run phase rate of footprint is slow, reaches 41% Cloudscape load a large number of classes during the execution phase.

17. Experiments for Startup Time Measurements First server instance 5.8% decrease in startup time The second and subsequenct server instance decrease in startup time to 77.3% Mserver has already loaded the network class for Jlogin and main body of the server classes

18. Throughput Measurements Performance gain from two source: • MVM share class runtime representations across application The other use that class without engage in file fetching, parsing, verifying. • Several Java components working in the same process Process switching is avoided when they communicate

19. References [1] Mick Jordan, Laurent Daynès, Grzegorz Czajkowski, Marcin Jarzab, and Ciarán Bryce , "Scaling J2EE™ Application Servers with the Multi-Tasking Virtual Machine", ACM Portal, June 2004 [2] Janice J. Heiss, " The Multi-Tasking Virtual Machine: Building a Highly Scalable JVM", http://java.sun.com/developer/technicalArticles/Programming/mvm/, March 22, 2005 [3] Laurent Daynès, "Multi-tasking Virtual Machines", Sun Microsystems Laboratories

20. Scaling J2EE™ Application Servers withthe Multi-Tasking Virtual Machine The end 24.12.2009