We now consult the JAVA_HOME environment variable to determine where
to find the system library JARs and SOs. Ultimately, we'll want to
support self-contained build, but this allows Avian to behave like a
conventional libjvm.so.
Previously, we only built platform specific code in an
options-specific directory (e.g. build/linux-x86_64-debug), but built
the Java classes in the shared, top-level build directory. This
minimized duplication when building with different sets of options,
but now that we're supporting the option of selecting a third-party
class library, we need to put the classes in the options-specific
directory as well.
The main changes in this commit ensure that we don't hold the global
class lock when doing class resolution using application-defined
classloaders. Such classloaders may do their own locking (in fact,
it's almost certain), making deadlock likely when mixed with VM-level
locking in various orders.
Other changes include a fix to avoid overflow when waiting for
extremely long intervals and a GC root stack mapping bug.
The biggest change in this commit is to split the system classloader
into two: one for boot classes (e.g. java.lang.*) and another for
application classes. This is necessary to make OpenJDK's security
checks happy.
The rest of the changes include bugfixes and additional JVM method
implementations in classpath-openjdk.cpp.
Whereas the GNU Classpath port used the strategy of patching Classpath
with core classes from Avian so as to minimize changes to the VM, this
port uses the opposite strategy: abstract and isolate
classpath-specific features in the VM similar to how we abstract away
platform-specific features in system.h. This allows us to use an
unmodified copy of OpenJDK's class library, including its core classes
and augmented by a few VM-specific classes in the "avian" package.
We were incorrectly returning an empty array when the input was empty,
whereas we ought to return an array containing a single empty string.
When the pattern to match was empty, we went into a loop to create an
infinite list of empty strings, only to crash once we've run out of
memory. This commit addresses both problems.
We've been getting away with not doing this so far since our Java
calling convention matches the native calling convention concerning
where the return address is saved, so when our thunk calls native code
it gets saved for us automatically. However, there was still the
danger that a thread would interrupt another thread after the stack
pointer was saved to the thread field but before the native code was
called and try to get a stack trace, at which point it would try to
find the return address relative to that stack pointer and find
garbage instead. This commit ensures that we save the return address
before saving the stack pointer to avoid such a situation.
In order to facilitate making the VM compatible with multiple class
libraries, it's useful to separate the VM-specific representation of
these classes from the library implementations. This commit
introduces VMClass, VMField, and VMMethod for that purpose.
Note the following excerpt from PNGFileFormat.java in SWT:
/*
* InflaterInputStream does not consume all bytes in the stream
* when it is closed. This may leave unread IDAT chunks. The fix
* is to read all available bytes before closing it.
*/
while (stream.available() > 0) stream.read();
stream.close();
This code relies on the documented behavior of
InflaterInputStream.available, which must return "0 after EOF has been
reached, otherwise always return 1". This is unlike
InputStream.available, which is documented to return "the number of
bytes that can be read (or skipped over) from this input stream
without blocking by the next caller of a method for this input
stream", and says nothing about how many bytes are left until the end
of stream.
This commit modifies InflaterInputStream.available to behave according
to Sun's documentation.
A long time ago, I refactored the class initialization code in the VM,
but did not notice until today that it had caused the
process=interpret build to break on certain recursive initializations.
In particular, we were not always detecting when a thread recursively
tried to initialize a class it was already in the process of
initializing, leading to the mistaken assumption that another thread
was initializing it and that we should wait until it was done, in
which case we would wait forever.
This commit ensures that we always detect recursive initialization and
short-circuit it.
In PersistentSet.remove, we were modifying the child node in place
instead of making a copy to update, which would corrupt older
revisions. This commit ensures that we always create a copy if
necessary.
The shiftLeftC function in powerpc.cpp was miscompiling such shifts,
leading to crashes due to illegal instructions and other weirdness due
to instructions that meant something completely different. This
commit fixes that and adds a test to Longs.java to make sure it stays
fixed.
Previously, we risked segfaults by passing negative numbers to memcpy.
This commit also makes arraycopy throw an IndexOutOfBounds exception
instead of an ArrayStoreException if the specified offsets and lengths
would take us outside the bounds of one or both of the arrays, per the
Sun documentation.
