If a class references a field or method as static and we find it's
actually non-static -- or vice-versa -- we ought to throw an error
rather than abort.
The usage statement for the bootimage-generator now looks like this:
build/linux-x86_64-bootimage/bootimage-generator \
-cp <classpath> \
-bootimage <bootimage file> \
-codeimage <codeimage file> \
[-entry <class name>[.<method name>[<method spec>]]] \
[-bootimage-symbols <start symbol name>:<end symbol name>] \
[-codeimage-symbols <start symbol name>:<end symbol name>]
The first problem was that, on x86, we failed to properly keep track
of whether to expect the return address to be on the stack or not when
unwinding through a frame. We were relying on a "stackLimit" pointer
to tell us whether we were looking at the most recently-called frame
by comparing it with the stack pointer for that frame. That was
inaccurate in the case of a thread executing at the beginning of a
method before a new frame is allocated, in which case the most recent
two frames share a stack pointer, confusing the unwinder. The
solution involves keeping track of how many frames we've looked at
while walking the stack.
The other problem was that compareIpToMethodBounds assumed every
method was followed by at least one byte of padding before the next
method started. That assumption was usually valid because we were
storing the size following method code prior to the code itself.
However, the last method of an AOT-compiled code image is not followed
by any such method header and may instead be followed directly by
native code with no intervening padding. In that case, we risk
interpreting that native code as part of the preceding method, with
potentially bizarre results.
The reason for the compareIpToMethodBounds assumption was that methods
which throw exceptions as their last instruction generate a
non-returning call, which nonetheless push a return address on the
stack which points past the end of the method, and the unwinder needs
to know that return address belongs to that method. A better solution
is to add an extra trap instruction to the end of such methods, which
is what this patch does.
For some reason, Cygwin's MinGW-W64 compilers end up pulling in our
version of process.h from unistd.h. That doesn't really make sense --
it should use the one from the sysroot, but we can work around it by
just not including unistd.h, since it's not needed on Windows anyway.
OpenJDK is huge, so building a bootimage out of the whole thing (as
opposed to an app shrunk using ProGuard) requires a lot of space.
Note that we still can't handle this on ARM or PowerPC due to a
limitation in the compiler, but we don't expect people to ship
binaries with the entire OpenJDK class library anyway, so it shouldn't
be a problem in practice.
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.
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.
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.
