File Release Notes and Changelog
Notes:
JamVM 1.4.4 is a feature and bug-fix release.
Changes:
A summary of changes since 1.4.3:
- Full JNI Invocation API implemented, enabling JamVM to be linked into
another program.
- JNI_CreateJavaVM, DestroyJavaVM, AttachCurrentThread,
- AttachCurrentThreadAsDaemon, DetachCurrentThread
- JNI_GetDefaultJavaVMInitArgs
- JamVM is now also built as a shared library (lib/libjvm.so).
- The executable (bin/jamvm) is statically linked with this library
instead of being a wrapper. This is because the shared library
runs slower than static linking on some architectures. As JamVM
is small this is not a problem.
- Improved class-loader and shared library support
- When a class-loader (and all its classes) is unloaded all shared
libraries loaded by the class-loader are unloaded and JNI_OnUnload
called (if defined)
- A shared library can no longer be opened by two class-loaders
at once
- A class can only resolve native methods defined in shared libraries
opened by its defining class-loader
- Major re-working of thread/locking code to support additional Java 1.5
functionality
- Thread.getState() implemented
- correct thread states and their transistions (e.g. BLOCKING,
WAITING, TIMED_WAITING, etc.)
- native support for the ThreadMXBean thread system management API
- thread creation statistics (count of live, started and
peak threads)
- Information about a thread (ThreadInfo)
- execution information (thread state, stack backtrace to
a particular depth, object upon which the thread is blocked
or waiting to be notified)
- synchronization statistics (counts of the times the thread
has been blocked or waited for notification)
- Thread.interrupt() re-implemented fixing several bugs
- if a thread was waiting on a monitor, previous implementation
required the monitor lock to be obtained. If a 3rd thread
was holding this, the interrupt could not occur to avoid
deadlock. New thread-code does not require lock to be obtained.
- in rare circumstances another thread waiting on the monitor
could be notified (when there was pending notifications,
and then an interrupt, and subsequent threads waiting on the
monitor).
- a thread waiting on a thin-lock (waiting for inflation)
could erroneously report an InterruptedException
- GC bug fix for class-unloading when only using the compactor
(-Xcompactalways). The compactor in some circumstances could move
objects ontop of the object holding the native class-loader VM data
before it was freed leading to a SEGV.
- Bug fix for abstract methods which fell through previous
AbstractMethodError checks (using a stub method)
- AbstractMethodError now also gives the method name
- Bug fix to not allow abstract classes to be instantiated
- Bug fix for NULL in identityHashCode (a regression in JamVM 1.4.3)
- Bug fix for NULL in JNI method GetStringUTFLength|Chars
- Bug fix for $ in native method names
- FirstNonNullClassLoader implemented
- Access-checking bug fix. In reflection method/field access, also
check class access in addition to method/field.
- Ensure created threads have a native stack size of at least 2MB. This
fixes SEGVs due to stack overflow seen on OpenBSD/Darwin
(default 512KB).
- Property sun.boot.class.path is now also defined in addition to
java.boot.classpath. Certain applications look for the Sun property
(e.g. Dacapo bloat benchmark).
- Extra bootclasspath command line options
- bootclasspath/v overrides the default VM classes path
- bootclasspath/c overrides the default GNU Classpath classes path
- java.endorsed.dirs support added
- directories are scanned and any jar/zip files are added to the
boot classpath.
- Improved thread dump (produced via ctrl-\). Now shows thread state.
- JamVM by default now installs in its own directory (/usr/local/jamvm)
