fix crash in findFrameMapInSimpleTable due to bug in instanceof implementation

We weren't adding entries to the frame map for calls to the instanceof
thunk when compiling methods.  However, that thunk may trigger a GC,
in which case we'll need to unwind the stack, which will lead to a
crash if we don't have a frame map entry for that instruction.
allow main thread to use DetachCurrentThread

When I originally implemented DetachCurrentThread, I assumed it didn't
make sense for the main thread to detach itself from the VM, and I was
concerned that allowing it might cause problems for any other threads
still attached.  However, detaching the main thread is allowed by the
JNI spec as of Java 2, and OpenJDK's java command does this just
before calling DestroyJavaVM.  Therefore, this commit ensures that the
VM doesn't abort if the main thread is detached.
Fix stacktrace when building with MSVC
set main thread context classloader correctly for OpenJDK port

sun.misc.Launcher has its own idea about what the application
classloader should be, but we need to override it with the system
classloader created by the VM.  This is achieved by running
Launcher.getLauncher (which has the side effect of setting
Thread.contextClassLoader) and then overriding it.
implement Runtime.maxMemory for OpenJDK port

Some apps refuse to run if Runtime.maxMemory returns a value that's
"too small", so our stub implementation returning zero was not
sufficient.  Now we return the actual heap size limit in bytes.
implement JVM_ConstantPoolGetDoubleAt
don't throw an exception from resolveClass when throw_ == false

resolveClass was correctly respecting throw_ == false if the requested
class was not found, but it still threw an exception if e.g. the
superclass was missing.  Now we catch such exceptions and return null
as appropriate.
fix memcpy argument order bug in jvmConstantPoolGetDoubleAt
fix 64-bit shifts on x86_32 (part 2)

My earlier attempt (fa5d76b) missed an important detail, and somehow I
forgot to test the 32-bit OpenJDK build which made that omission
obvious.  Here's the fix.
Add a non-versioned SONAME to Avian libjvm.so that
matches the Hotspot Server/Client libjvm.so SONAME,
this allow libjava.so in OpenJDK 7 to find the Avian libjvm.so during ldopen.
Set java.vm.info based on makefile info= and
set java.vm.version based on makefile version=
in order to display relevant OpenJDK -version information.

Signed-off-by: Matthias Klose <doko@ubuntu.com>
Signed-off-by: Xerxes Rånby <xerxes@zafena.se>
Merge branch 'openjdk-version' of https://github.com/xranby/avian
ignore DetachCurrentThread calls for the main thread

My earlier commit to allow detaching the main thread (1f1c3c4) seems
to have caused subtle stability problems
(e.g. https://groups.google.com/group/avian/msg/d2c797c0dcf925c3), so
for now we'll just ignore that operation, which leaks a bit of memory
but should be harmless otherwise.
add JNI_GetCreatedJavaVMs stub

Recent versions of IcedTea will not run unless libjvm.so exports this
symbol.  The quick fix is to provide a stub which just always returns
-1 to indicate an error.  I'll leave a proper implementation for when
we need to support an app that actually uses this function.
fix sun.misc.Unsafe.getLongVolatile for static fields on 32-bit platforms

The existing code did not handle static field lookups for
synchronization on 32-bit systems, which is necessary because such
systems generally don't support atomic operations on 64-bit values.
fix reads of out-of-bounds values in tokenizer.h
fix incorrect reporting of fixie collection status in heap.cpp (part 2)

My earlier fix (f8e8609) was almost -- but not quite -- sufficient.
It asked the heap to mark the dead fixies too early, so some of them
were marked dead even though they ultimately survived, causing us to
clear weak JNI references when we shouldn't.
fix a couple of ByteBuffer regressions

The compact() and put(ByteBuffer) methods regressed as of the recent
refactoring to support direct byte buffers.
fix a couple of OpenJDK reflection bugs

We weren't wrapping exceptions thrown by invoked methods in
InvocationTargetExceptions in JVM_InvokeMethod or
JVM_NewInstanceFromConstructor.  Also, JVM_GetCallerClass is supposed
to ignore Method.invoke frames when walking the stack.
make JVM_GetSystemPackage a bit smarter

The original stub implementation just echoed back its argument, but
that confused URLClassLoader when dealing with sealed JARs --
returning a non-null value for a non-system class from
JVM_GetSystemPackage made URLClassloader think it had already loaded a
class from a package which was supposed to be sealed, resulting in
SecurityExceptions which ultimately triggered NoClassDefFoundErrors.
The solution is to only return non-null values for actual system
classes.