If we don't initialize that at our first opportunity, it's possible
we'll run out of memory later and exit silently instead of printing
the error and returning a nonzero exit code.
It seems that GCC 4.6.1 gets confused at LTO time when we take the
address of inline functions, so I'm switching them to non-inline
linkage to make it happy.
When link time optimization is enabled, we need to remind the compiler
that we're targeting i586 when linking so it can resolve atomic
operations like __sync_bool_compare_and_swap.
The JRE lib dir for OpenJDK 7 on OS X seems to be just "lib", not
e.g. "lib/amd64" by default, so we use that now. Also, the default
library compatibility version for libjvm.dylib is 0.0.0, but OpenJDK
wants 1.0.0, so we set it explicitly.
If we clear Thread::flags before releasing the thread mutex and
re-acquiring the monitor mutex, it's possible that we will be notified
between the release and re-acquire, which will confuse us later if we
try to wait on the same monitor again such that we well not remove
ourselves from the wait list because we think we've been removed by
the notifier.
The solution is to wait until we've acquired both mutexes before we
clear Thread::flags.
We've already been handling this case in arm.cpp and powerpc.cpp, but
apparently we've never hit this code path in x86.cpp before. Indeed,
I've been unable to come up with a Java source code test that hits it;
it's only come up in Scala-generated bytecode.
Scala occasionally generates exception handler tables with interval
bounds which fall outside the range of valid bytecode indexes, so we
must clamp them or risk out-of-bounds array accesses.
Since we use Thread::code to store a reference to either the method to
be invoked or the current bytecode being executed depending on the
context, we must be careful to switch it back to the bytecode of the
exception handler if an exception is thrown while invoking a method
(e.g. an UnsatisfiedLinkError).
There was a subtle bug in that we were not considering alignment
padding for fields defined in superclasses when calculating field
offsets for a derived class when the superclass(es) were visited by
the bootimage generator before the derived class.
