Version 1.0 ----------- * We include a prototype implementation of an emerging standard, the JSR-121 Application Isolation API Specification, or "Isolate", that exploits the JanosVM's capabilities. This is not the formal RI for JSR-121. JSR-121 is still in progress and may change from what is included here. Our implementation allows developers to experiment with this emerging standard interface to start and safely terminate Java processes-- in our case, within a single JVM. Utah contributes to the JSR-121 spec by having a representative, Patrick Tullmann, on the JSR-121 Expert Group, as well as through our earlier research in this area. The JSR-121 prototype is in libraries/kitlib/java/lang/isolate. It is a single address space implementation that maps Isolate instances to JanosVM teams. It provides all the isolation support, such as asynchronous termination, as well as Link functionality, like passing open file/socket streams. As a demonstration of the JSR-121 prototype there are several test programs in the libraries/kitlib/edu/utah/janosvm/apps directory. The 'isoshell' is a simple shell that starts Java programs in sub-isolates. The 'isoserv' is a simple web server that splits functionality across isolates to enhance reliability and to protect the server from untrusted 'servlet' code. For example, requests for static web pages are handled by the main web server isolate passing the open stream to a static page helper isolate. This separation reduces the amount of code in the main web server and makes it possible to easily restart faulty helper isolates. See Section 4.6 of the tutorial for more detail. * Significant resource management in Unix-Jthreads2: Unix JThreads2 is now the default threading system. Stack overflows are now detected using a guard page instead of passing the maximum stack limit with the method call. The implementation uses the process' alternate signal stack to initially catch and handle the SIGSEGV. Next, the signal handler changes the sigcontext to use a per-thread exception stack. Finally, the handler returns and the thread continues normally, using the separate stack to build and throw the exception. A file system resource specification, FileSystemSpec, was added to support chroot()-like behavior. See FSTest.java in test/janosvm for example usage. The CPUSpec now takes a 'limit' parameter that specifies a maximum for total CPU usage. If a team crosses this limit it will trigger a CPU_OVERDRAW team event. See CPULimit.java in test/janosvm for example usage. A file descriptor resource specification, DescriptorIOSpec, was added to support limits on per-team descriptor counts. See IOTest.java in test/janosvm for example usage. Resource monitoring for the VM can be done using the client/server mode of GKrellM (www.gkrellm.net). Simply start the JVM with JSI turned on (e.g. -jsitcpport 8192) and run the jvm_gkrellmd.py script in libraries/unsupported/jsi/pylib. This script will adapt the resource accounting provided through JSI to the GKrellMd protocol. Here is an example run: 1> janosvm -jsitcpport 14000 ... & 2> jvm_gkrellmd.py -t tcp:localhost/14000 -p 14001 & 3> gkrellm -s localhost -P 14001 * It is _highly_ recommended that you download and install the Jikes compiler, version 1.18. You can get the latest release from: http://oss.software.ibm.com/developerworks/opensource/jikes/ JanosVM includes the Java-based KJC compiler, however, it generates bad code in certain circumstances and is generally not trustworthy at the moment. Also, the precompiled JAR files included in the distribution were generated with Jikes. So, if you recompile without Jikes there will be several more failures in the test suite. * Run-time access checking of method and field references is mostly implemented. For example, a method that tries to reference a private field in another class will cause an IllegalAccessException to be thrown. The test suite has also been modified to support testing of this functionality by using the compile_time and run_time directories in test/regression. When compiling, the compile_time is included in the class path, and when executing the test, the run_time directory is included. Thus, tests can be written that use classes that differ from compile-time to run-time. For example, implementing the previously mentioned illegal access is done by writing a class with a public field named 'foo' in the compile_time directory, while the run_time directory has the same class with a private 'foo.' * Support was added to make class loading lazier. Compiled methods will now defer loading classes until the code is executed. For example, the following code will not load the 'Bar' class until 'a' is true: public void foo(boolean a) { if( a ) { new Bar().b = 42; } } The deferral is done by having the method call a function in soft.c that loads the class and, in the above case, returns the address of the field. Unfortunately, the INSTANCEOF and CHECKCAST bytecodes still aggressively load classes during verification and not when they are actually referenced. * In addition to lazier class loading, errors during loading are handled better. For example, the JVM will retry loading classes that are not found or failed to pass a stage preceding the execution of the static initializer. * As a byproduct of the lazy loading work, support was added for recompiling methods. Because methods with lazy lookups must go through the sub-optimal deferral process, recompilation makes it possible to eventually generate 'optimal' code. As such, jitted code is now garbage collected and the finalizer thread has been tasked with doing the actual recompiling work. * The old-style methodCache.*, used to map program counter values to methods, has been thrown away. Instead, the jitter now prepends a header containing the relevant information onto the code block. Mappings are then done by asking the garbage collector for the base pointer of the given PC value, which should be the header. * Stricter checking of class file formats has been added. Access flags, constant pool references, method signatures, field signatures, and other attributes are validated and programmed to throw exceptions that match the ones used by JDK 1.3.1. * The test suite now takes advantage of the Jasmin Java assembler to test the class file reader. It should automatically be detected by configure. The test suite now takes advantage of the ByteCode Engineering Library (BCEL) to test the integrity of the class file reader. It can be turned on by configuring with '--with-bcel=/bcel.jar'. * Support for motherboard temperature and fan sensors has been added for FreeBSD. Support is handled by including parts of the 'xmbmon' sources available from: http://www.nt.phys.kyushu-u.ac.jp/shimizu/download/download.html It can be turned on by configuring with '--with-xmbmon=/xmbmon200'. Note: You must have the proper permissions for this to work properly. * The JanosVM.jar file now only includes the differences from the the standard rt.jar. This makes it easier to maintain, however, you must include rt.jar in the class path after JanosVM.jar when compiling. Also, more of the standard Java run-time components have been 'JanosVMized' so they work correctly in the multi-process environment. * Class groups can now be imported after the team has been created using the NameSpaceResource.importClassGroup() method. This method is then used by the class loader, 'Loader', located in libraries/kitlib/edu/utah/janosvm/kit/loader to support on-the-fly starting of server teams and importation of their classes. In addition, the JVM now understands the '-Xloader' argument which specifies a class that will load and execute the main class. As an example, the 'jisovm' script uses the loader to create the root JSR-121 isolate and start a server team that is responsible for housing the java.lang.isolate.* classes. * Added the java.net.NetworkInterface from JDK 1.4. Currently, it is implemented using getifaddrs() as provided by the OS or the Linux implementation in replace/ifaddrs_linux.c. * ArrayIndexOutOfBoundsExceptions and NegativeArraySizeExceptions now contain the bad index value. This matches the Sun behavior and is just plain helpful for debugging. * Internal failures will cause a, hopefully helpful, message to be printed. It is hoped that this will help the users give the maintainers the information they need to find the problem. * Synchronized with the Kaffe CVS repository on February 6, 2003.