Transcript Scaling J2EE™ Applic..

Scaling J2EE™ Application Servers with
the Multi-Tasking Virtual Machine
Razieh Asadi
University of Science and Tecnology
Mazandran Babol
 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
 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
- 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. Amount
of memory and CPU usage.
- 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.
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.
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.
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)
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
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()).
MVM architecture
request
Jlogin
MVM architecture

Operation of the MVM
1.
2.
3.

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
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
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
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).

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.

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
Throughput Measurements
Performance gain from two source:
1.
MVM share class runtime representations across
application
The other use that class without engage in file fetching,
parsing, verifying.
2.
Several Java components working in the same
process
Process switching is avoided when they communicate
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
Scaling J2EE™ Application Servers with
the Multi-Tasking Virtual Machine
The end
24.12.2009