|
|
|
Last updated 06/28/04
What is JavaCI?
In the 2001 System Improvement Ballot (SIB) for MPE/iX, users
asked for 'faster Java VM startup'. JavaCI grew out of the
effort to satisfy this basic requirement.
Essentially, while there are some opportunities for performance
tuning within the Java VM startup code, any improvements would
be on the order of 5% to 10%, when what was needed was an
order-of-magnitude breakthrough. It became obvious early on
that any perceived improvement in VM startup would likely
come from pre-starting a Java VM, so that there was no
waiting time when the user types 'java className'.
Initial design was based on the concept of a pool of VMs,
but much of the time saved by precreating the VMs ended up
being lost by the need to adopt the VM into the user's
session environment (to provide proper security, plus
access to environment variables and other context-dependent
features).
The idea that resulted was to integrate the Java VM with the
MPE/iX Command Interpreter. The overhead of starting the JVM
could be limited to once per session, rather than once per
invocation of Java, and the JVM would have appropriate access
to all of the Job/Session context. For various technical
reasons, it was not possible to have the MPE/iX start and
maintain a Java VM, but it did turn out to be possible for
a Java VM to provide a working environment that is virtually
identical to the MPE/iX Command Interpreter. This environment
is the JavaCI.
Users can choose to run the JavaCI when appropriate -- for users
that don't need access to Java at all, there is no reason to
run it. For occasional Java users, the JavaCI can be entered
whenever the user plans to do Java work. For users that use
Java heavily, they may choose to make the JavaCI their primary
working environment. JavaCI can be started as a son process
of the CI, or the :NEWCI command can be used to have JavaCI
replace the MPE/iX Command Interpreter altogether.
Benefits of using JavaCI
The time to load and begin executing a Java class from the
JavaCI environment is less than one second.
JavaCI provides an 'implied run' capability for Java classes.
Instead of needing to type 'java ClassName', you can simply
type the ClassName.
Limitations of JavaCI
BREAK is not supported within the JavaCI environment.
The JavaCI only provides fast java startup from the MPE/iX
CI environment; no benefit is seen from the POSIX shell.
Currently, only java, javac, and jar command invocations are
handled through the 'fast path'; other command line utilities
(such as rmic) will cause a new VM to be created.
Any arguments passed to the Java VM, such as changes to heap
size, -verbose, etc., will result in a new VM being created.
Challenges in implementing JavaCI
Just for those of you who might be curious about the details of
JavaCI, I'll share some of the things that needed to be handled in
order for JavaCI to reach its current state.
Most CI functionality is merely a pass-thru using HPCICOMMAND.
The CI's variable expansion capability is leveraged for java
commands, so :java !classname is perfectly legal.
Since :DO and :REDO aren't programatically executable, the
JavaCI maintains its own redo stack.
JavaCI also has its own implementation of :CHGROUP, :EXIT, and :BYE.
A custom SecurityManager had to be written to prevent programs
which call System.exit() from terminating JavaCI.
A custom ClassLoader had to be written to allow changes to
the CLASSPATH (via :SETVAR) while the VM was running, and
also to permit reloading of classes that might be recompiled
during JavaCI execution.
Documentation
view JavaCI User's Guide here (doc)
(PDF format)
The is an MS-Word format User's Guide which provides a bit more
technical and usage information than is available from this page.
Download and install JavaCI runtime
- Download the JavaCI runtime here
- Upload the tarfile to your HP e3000, making sure to preserve the
filetype as 'binary' or 'bytestream' (from a Windows PC you would
use the ftp command 'type tenex').
- Log on as MANAGER.SYS
- Start the posix shell.
:sh.hpbin.sys -L - The tarfile was created using relative (not absolute) pathnames
so you need to be in the root directory before untarring it.
cd / - Untar. This command assumes you uploaded the tarfile to the
/tmp directory.
tar -xovpf /tmp/javaci.tar
4 files will be installed:
JAVACI.PUB.SYS - used to invoke JavaCI
/usr/local/java/latest/jre/lib/ext/javaci.jar
JavaCI classes installed in the extensions directory.
/usr/local/java/latest/jre/lib/ext/.javaci.policy
Sets security for the custom class loader. We hope to remove this
in the future.
/usr/local/java/latest/jre/lib/PA-RISC/libjavaci.sl
Native code shared library.
Download and install JavaCI source code
- Download the JavaCI source code here
- Upload the tarfile to your HP e3000, making sure to preserve the
filetype as 'binary' or 'bytestream' (from a Windows PC you would
use the ftp command 'type tenex').
- Log on as MGR.JAVA
- Start the posix shell.
:sh.hpbin.sys -L - The tarfile was created using relative (not absolute) pathnames
so you need to be in the /JAVA/DEMO directory before untarring it.
cd /JAVA/DEMO - Untar. This command assumes you uploaded the tarfile to the
/tmp directory.
tar -xovpf /tmp/javaci_src.tar
All files should now be installed in /JAVA/DEMO/com/hp/javaci.
The Makefile has these targets:
clean
default (or just type 'make')
doc - creates Javadoc. Useful if your e3000 is a web server.
runtime - creates the tarfile for a runtime distribution
install - Log on to MANAGER.SYS and cd /JAVA/DEMO/com/hp/javaci
FIRST. This is used to install the just built javaci on your local
system. Recommend using at least 2 windows, one for MGR.JAVA where you
do 'make' and one for MANAGER.SYS where you do 'make install'.
distribution - creates the tarfile with all the source code
(like the one where you got all this good stuff in the first place :-)
JavaCI futures
There are a number of features that may be added to JavaCI in the
future; we'd really like to hear feedback from users to allow us
to prioritize them. To get the ball rolling, here are some
features we've already thought about (but haven't committed to
implementing):
A 'jsh' shell workalike based on JavaCI architecture.
Support for break/abort/resume within JavaCI.
The ability to call any arbitrary Java API from a CI command line.
This is potentially very powerful, but requires extension of
CI semantics to support variable typing and function declaration.
Using Java to implement new CI functions, for example spoolinfo(),
acctinfo(), devinfo(), etc.
|