* Unsafe.arrayIndexScale was always returning the native word size,
due to a thinko on my part
* Unsafe.getLongVolatile and putLongVolatile did not work for array
elements on 32-bit systems
Turns out Function can do the jobs of both CallbackReceiver and
FunctionReceiver, so I've removed the latter two.
Also, shift and reset should work with a combination of types, not
just a single type, so I've expanded their generic signatures.
There's more work to do to derive all the properties of a given class
from its code source (e.g. JAR file), but this at least ensures that
ClassLoader.getPackage will actually return something non-null when
appropriate.
classpath-common.h's getDeclaringClass was trying to look up
non-existing classes, which led to an abort, and I don't even know
what Class.getDeclaredClasses was trying to do, but it was ugly and
wrong.
The various Architecture::nextFrame implementations were not walking
the stack correctly when a StackOverflowError was thrown. The
throwStackOverflow thunk is called before the frame of the most
recently called method has been fully created, and because tails=true
builds use a different calling convention, we need to treat this
situation carefully when building a stack trace or unwinding.
Otherwise, we will skip past all the java frames to the next native
frame, which is what was happening.
Tail call and dead code optimizations can cause code after a throw to
be eliminated, which confuses findUnwindTarget because it doesn't know
what code is throwing the exception. So we need at least one
instruction to follow the call to the throw_ thunk. Previously, we
only added such an instruction when we knew the throw was the last
instruction in the bytecode, but it turns out there are other cases
where it is needed, including certain try/finally situations.
This is the simplest possible ConcurrentHashMap I could come up with
that works and is actually concurrent in the way one would expect.
It's pretty unconventional, being based on a persistent red-black
tree, and not particularly memory-efficient or cache-friendly. I
think this is a good place to start, though, and it should perform
reasonably well for most workloads. Patches for a more efficient
implementation are welcome!
I also implemented AtomicReferenceArray, since I was using it in my
first, naive attempt to implement ConcurrentHashMap.
I had to do a bit of refactoring, including moving some non-standard
stuff from java.util.Collections to avian.Data so I could make it
available to code outside the java.util package, which is why I had to
modify several unrelated files.
getDeclaredMethods was returning methods which were inherited from
interfaces but not (re)declared in the class itself, due to the VM's
internal use of VMClass.methodTable differing from its role in
reflection. For reflection, we must only include the declared
methods, not the inherited but un-redeclared ones.
Previously, we saved the original method table in
ClassAddendum.methodTable before creating a new one which contains
both declared and inherited methods. That wasted space, so this patch
replaces ClassAddendum.methodTable with
ClassAddendum.declaredMethodCount, which specifies how many of the
methods in VMClass.methodTable were declared in that class.
Alternatively, we could ensure that undeclared methods always have
their VMMethod.class_ field set to the declaring class instead of the
inheriting class. I tried this, but it led to subtle crashes in
interface method lookup. The rest of the VM relies not only on
VMClass.methodTable containing all inherited interface methods but
also that those methods point to the inheriting class, not the
declaring class. Changing those assumptions would be a much bigger
(and more dangerous in terms of regression potential) effort than I
care to take on right now. The solution I chose is a bit ugly, but
it's safe.
An inner class has two sets of modifier flags: one is declared in the
usual place in the class file and the other is part of the
InnerClasses attribute. Not only is that redundant, but they can
contradict, and the VM can't just pick one and roll with it. Instead,
Class.getModifiers must return the InnerClasses version, whereas
reflection must check the top-level version. So even if
Class.getModifiers says the class is protected, it might still be
public for the purpose of reflection depending on what the
InnerClasses attribute says. Crazy? Yes.
This makes them available in all class libraries, not just the OpenJDK
library. Note that I've also removed the unecessary idle statements,
per ab4adef.
Android's class library uses this to find out whether the VM supports
compareAndSwapLong natively. Avian does on all platforms, so we just
return true.
There's a small optimization in compileDirectInvoke which tries to
avoid generating calls to empty methods. However, this causes
problems for code which uses such a call to ensure a class is
initialized -- if we omit that call, the class may not be
initialized and any side effects of that initialization may not
happen when the program expects them to.
This commit ensures that the compiler only omits empty method calls
when the target class does not need initialization. It also removes
commented-out code in classpath-openjdk.cpp which was responsible for
loading libmawt proactively; that was a hack to get JogAmp to work
before we understood what the real problem was.
Previously, we used "lzma:", which worked fine on Windows (where the
path separator is ";") but not on Unix-style OSes (where the path
separator is ":"). In the latter case, the VM would parse
"[lzma:bootJar]" as a path containing two elements, "[lzma" and
"bootJar]", which is not what was intended. So now we use "lzma." as
the prefix, which works on all OSes.
armv7 and later provide weaker cache coherency models than armv6 and
earlier, so we cannot just implement memory barriers as no-ops. This
patch uses the DMB instruction (or the equivalent OS-provided barrier
function) to implement barriers. This should fix concurrency issues
on newer chips such as the Apple A6 and A7.
If you still need to support ARMv6 devices, you should pass
"armv6=true" to make when building Avian. Ideally, the VM would
detect what kind of CPU it was executing on at runtime and direct the
JIT compiler accordingly, but I don't know how to do that on ARM.
Patches are welcome, though!
When calculating field offsets in the bootimage generator, we failed
to consider alignment at inheritence boundaries (i.e. the last field
inherited by from a superclass should be followed by enough padding to
align the first non-inherited field at a machine word boundary). This
led to a mismatch between native code and Java code in terms of class
layouts, including that of java.lang.reflect.Method.
The former just defers to the latter for now, since it provides
strictly weaker guarantees. Thus it's correct to use full
volatile-style barriers, though not as efficient as it could be on
some architectures.
Clang was complaining that newIp might be used uninitialized at the
bottom of our giant, unstructured compile loop, so I initialized it
with a bogus value, which means it will at least fail consistently if
Clang is right and there really is a path by which that code is
reached without otherwise initializing newIp.
It looks like the iOS 7 SDK doesn't have GCC anymore, so we need to
use clang instead. Also, thread_act.h and thread_status.h have moved,
so I updated arm.h accordingly. That might break the build for older
SDKs, but I don't have one available at the moment. If it does break,
I'll fix it.
Unsafe.compareAndSwapLong was moved from classpath-openjdk.cpp to
builtin.cpp, but the fieldForOffset helper function was not, which
only caused problems when I tried to build for ARM. This commit moves
said helper function, along with Unsafe.getVolatileLong, which also
uses it.
Most of these regressions were simply due to testing a lot more stuff,
esp. annotations and reflection, revealing holes in the Android
compatibility code. There are still some holes, but at least the
suite is passing (except for a fragile test in Serialize.java which I
will open an issue for).
Sorry this is such a big commit; there was more to address than I
initially expected.
Method.invoke should initialize its class before invoking the method,
throwing an ExceptionInInitializerError if it fails, without wrapping
said error in an InvocationTargetException.
Also, we must initialize ExceptionInInitializerError.exception when
throwing instances from the VM, since OpenJDK's
ExceptionInInitializerError.getCause uses the exception field, not the
cause field.
This is by no means a complete support for the deserialization compliant
to the Java Language Specification, but it is better to add the support
incrementally, for better readability of the commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Previously, we initialized it to the boot class loader, but that is
inconsistent with Java; if compiling against OpenJDK's class library,
the context class loader is therefore initialized to the app class
loader, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The findResources method is supposed to enumerate all the class path
elements' matching paths' URLs, but we used to stop at the first one.
While this is good enough when the system class path contains only a
single .jar file, since b88438d2(sketch of JAR support in Finder)
supports more than a single .jar file in the class path.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When the system class path contains more than one .jar, it is quite
concievable that, say, 'META-INF/MANIFEST.MF' can be found in multiple
class path elements.
This commit teaches the working horse of class path inspection, the
Finder class, how to continue the search at a given state.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When creating an object array with more than two dimensions, the
component type was erroneously set to the base type, not the array
type of one less dimension.
This prevented Collection<Class[]>#toArray(Class[][]) from working
properly.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This mainly involved reworking the makefile to avoid conflating
Darwin/ARM builds with iOS, since we may also want to build for the
iOS Simulator, which is i386.
Note that I was only able to test this on the Simulator, since I don't
have a real iOS device to test with. Sorry if I broke something; if
so, please fix it :)
GCC now assumes by default that the stack is aligned to a 16-byte boundary in Linux x86, so let's do our part to honour that. :)
Otherwise native code that depends on the stack to be aligned to 16 bytes would seg fault (like SSE).
https://groups.google.com/forum/#!topic/avian/SyCl-Jfw2U8
Previously, I used a shell script to extract modification date ranges
from the Git history, but that was complicated and unreliable, so now
every file just gets the same year range in its copyright header. If
someone needs to know when a specific file was modified and by whom,
they can look at the Git history themselves; no need to include it
redundantly in the header.
There were two issues: the linux->darwin cross compiler is more stringent
about unused variables, and the makefile specified flags for building ON
darwin that were actually applicable whenever we are building FOR darwin.
The original implementation was based on the assumption that the
passed class would be the array element type, whereas it is actually
the array type itself.
It may leak file handles under certain circumstances to do nothing in
JVM_UnloadLibrary, but, for now, an empty implementation is more
useful than one that aborts the process.
At one point, loading libmawt ahead of time was necessary to make AWT
work, but recent versions of OpenJDK seem to take care this from Java
code, in which case loading it ahead of time causes trouble, so we
comment it out for now until we exactly when it's needed.
Previously, we would attempt to initialize a class (e.g. call its
static initializer) whenever a method in that class was called, as
well as in any of the cases listed in
http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.4.
However, the above approach may lead to deadlock in an app which
relies on being able to call non-static methods in parallel with a
static initializer invocation in the same class. Thus, this commit
ensures that we initialize classes only in the cases defined by the
standard.
Since park does not throw InterruptedException, we must leave the flag
set if we are interrupted while parked so that
e.g. AbstractQueuedSynchronizer can itself throw an exception if
appropriate.
This mainly moves several sun.misc.Unsafe method implementations from
classpath-openjdk.cpp to builtin.cpp so that the Avian and Android
builds can use them.
It also replaces FinalizerReference.finalizeAllEnqueued with a no-op,
since the real implementations assumes too much about how the VM
handles (or delegates) finalization.
We must be in the Active state, not the Exclusive state when calling
this method since it may execute arbitrary Java code. This fixes an
assertion failure in makeNew.
scalac may generate bytecode such that an exception is thrown within
the bounds of a handler for that exception such that the throw is the
last instruction in the method, which we weren't handling properly.
The InnerClasses attribute may have entries for classes declared
inside classes we don't care about, so we must check each entry's
outer class reference and make sure it matches the one we do care
about.
scalac may emit a ldc followed by an i2c, whereas javac does the
conversion (including zero extension if necessary) at compile time.
This commit ensures we handle the i2c case properly.
If sun.java.command or sun.java.launcher are set, then the VM is being
loaded from e.g. libjvm.so, not as a stand-alone executable. This
commit allows libjvm.dylib to be used with OpenJDK's java command on OS
X.
The OpenJDK library wants to track and run the shutdown hooks itself
rather than let the VM do it, so we need to tell it when we're
exiting.
Also, in machine.cpp we need to use only the modifiers specified in
the InnerClasses attribute for inner classes rather than OR them with
the flags given at the top level of the class file.
scalac may generate a ldc followed by an l2i, whereas javac always
seems to condense this into a single ldc_w. The former exposed a bug
in the JIT compiler which we never hit with javac-generated bytecode.
This fixes a couple of tests in the Scala test suite
(run/reflection-modulemirror-toplevel-badpath.scala and
run/reflection-constructormirror-nested-good.scala).
This is necessary to ensure that new threads do not start while we're
shutting down (except for the ones that we start to run the shutdown
hooks), and that the shutdown hook threads can be safely started (it
is not safe to start threads from e.g. an idle state, and an assertion
will fail if we do).
This ensures that, if an exception is thrown later but before the
method has been fully compiled, we will know exactly how much memory
to free. Previously, we would abort when trying to free the wrong
amount due to an assertion failure.
It's amazing to me that ebp and esp have been swapped for over three
years without anybody noticing. It was dumb luck that the Trace test
(which is designed to catch just such a thing) happened to fail when I
ran the whole suite, and further investigation revealed that it was
failing maybe five percent of the times it was run. Now we know why.
Timezone code was broken in the Android class library bootimage build
because the code we use to intercept loading the tzdata file wasn't
working. The reason is have no way of intercepting static methods at
runtime in the bootimage build without telling the bootimage-generator
we're going to do it ahead of time. So now we do tell it so.
This commit also removes the need to intercept Thread methods since we
can update Thread.vmThread in VMThread.create instead.
In order for a thread to enter the "exclusive" state such that no
other threads are active in the VM, it must wait for all active
threads to enter the "idle" state. In order for this to happen in a
timely manner, threads must check frequently to see if a thread is
waiting to enter the exclusive state. These checks happen at every
memory allocation, wait, sleep, native call, etc. However, if a
thread is in a busy loop that does none of those things, it will block
any other thread from entering that state.
The proper way to address this is to detect such loops (or tail
recursion in tail-call-optimized builds) at compile or interpret time
and insert explicit checks. This hasn't been a high priority thus
far, though, since we had yet to encounter such code in the wild.
Now, however, we find that scala.concurrent.forkjoin.ForkJoinPool.scan
(and possibly some versions of java.util.concurrent.ForkJoinPool.scan,
on which we assume the former is based) has just such a loop.
Fortunately, that loop calls Unsafe.getObjectVolatile, which the VM
implements and thus can treat as a checkpoint. That's the workaround
we use in this patch.
Setting this property (e.g. -Davian.trace.port=5555) will cause the VM
to start an extra daemon thread which listens on the specified TCP
port for incoming connections and dumps stack traces for all running
threads to that socket. You can retrieve that dump using e.g. netcat:
nc localhost 5555
Objects which are eligable for finalization must be retained until
after their finalize methods are called. However, the VM must
determine the entire set of such objects before retaining any of them;
otherwise the process of retaining a given object may cause others to
become reachable and thus be considered ineligible for finalization
even though they are only reachable via other finalizable objects.
The end result of this mistake is that only a few of the objects which
are finalizable will be recognized at each GC cycle, so it requires
many such cycles to find them all, and if new objects become
finalizable at a faster rate, the VM will never catch up and
eventually run out of memory.
This patch fixes the above mistake and also includes tuning to
minimize the need for GC in low memory situations.
In the OpenJDK library, ThreadGroup maintains an array of all Threads
in that group, so the VM must explicitly remove threads as they exit
or else neither they nor any objects they reference will be eligable
for GC.
The original goal was to minimize memory usage by garbage collecting
more frequently and more comprehensively as we got closer to the heap
limit. In practice, though, this just slowed the VM to a crawl as
memory pressure increased. If an app really wants to use a lot of
memory, the VM shouldn't penalize it aside from throwing an
OutOfMemoryError if it exceeds the limit.
This is necessary to avoid name conflicts on various platforms. For
example, iOS has its own util.h, and Windows has a process.h. By
including our version as e.g. "avian/util.h", we avoid confusion with
the system version.
In type-generator, we were incorrectly calculating field offsets where
a class inherits from another class whose last field has a natural
alignment which is different from the native word size. Surprisingly,
this only popped up when I built using the Android class library on a
64-bit system.
Previously, if you forgot to use RUNTIME_ARRAY_BODY to reference an
array declared with (THREAD_)RUNTIME_ARRAY, you wouldn't get a
compiler error until you tried to build on e.g. MSVC, where
runtime-sized stack arrays aren't supported. This change ensures you
find out regardless of what compiler you're using, which ought to
protect us from regressions going forward.
It now builds and links, but fails at runtime because
register_libcore_icu_ICU can't find the file it wants. We'll probably need to replace register_libcore_icu_ICU with a better-behaved version.
Stuff compiles, but linking breaks spectacularly. Next step is to
figure out how to build the dependencies without checking out and
building the entire Android platform.
The eventual intent with the lir namespace is to formalize some of
the important bits of Assembler interface, to be tested, debug-printed,
and potentially, serialized.
Also, group arguments to apply(...) in OperandInfos
The primary motivation behind this is to allow all the different Assemblers
to be built at once, on a single machine. This should dramatically reduce
the time required to make sure that a particular change doesn't break
the build for one of the not-so-common architectures (arm, powerpc)
Simply pass "codegen-targets=all" to make to compile all
src/codegen/<arch>/assembler.cpp.
Note that while these architectures are built, they will not be fully-
functional. Certain stuff is assumed to be the same across the entire
build (such as TargetBytesPerWord), but this isn't the case anymore.
If we increment the value while we're still in IdleState, another
thread may try to GC before we are able to enter ActiveState, which
will lead to an assertion failure when the footprint function is
called.
"%*s" means "at least", whereas "%.*s" means at most, and the latter
is what I intended. This only became noticable as of 9f22a70, when I
added another directory to the library path, which caused loadLibrary
to fail to find libraries in either directory.
We must use separate va_start/va_end pairs for each call to vsnprintf
on Linux and possibly other platforms in order to avoid a crash.
Also, we need to give it room to null terminate the string at the
right point.
When GetStringCritical or GetPrimitiveArrayCritical are called, the VM
cannot risk new Java heap allocations until the corresponding release
method is called because allocations may result in GC, which cannot
happen while a string or array is pinned in memory. We already have a
check for this latter in the footprint function used during GC, but
it's best to catch the problem as early as possible.
Previously, we would blithely exceed the heap ceiling and force the
next allocation to deal with the problem, including a major GC and
possible OutOfMemoryError. As of this commit, we throw an error
immediately if we find that the allocation will push us over the
ceiling.
Scala sometimes generates bytecode such that the scope of an exception
handler starts at another exception handler, e.g.:
Exception table:
from to target type
290 372 382 any
382 451 451 any
290 372 451 any
Avian's compiler was incorrectly initializing the stack frame for the
second handler in this case. This commit fixes the problem.
The instruction for 32-bit-to-64-bit sign extension on x86_32 requires
that the input value be placed in EAX and the sign extension in EDX.
However, the compiler can get confused if the input value is in memory
addressed via one of those registers and doesn't know how to move it.
This patch works around that limitation by doing the move explicitly
in MemoryEvent::compile if necessary.
Method.invoke must throw an IllegalArgumentException if it receives
the wrong number or types of arguments, and since this isn't done by
the OpenJDK class library, we must do it in the VM.
This library is placed in the xawt subdirectory of jre/lib/$arch on
POSIX systems, so it isn't found automatically when third-party
libraries which depend on it are loaded. The simplest way to ensure
that it's found seems to be to just load it when the VM starts up.
In order to calculate the initial stack map of GC roots for an
exception handler, we do a logical "and" of maps across all the
instructions contained in the try block for that handler. This is
complicated by the presence of jsr/ret instructions, though, because
instructions in a subroutine may have multiple maps associated with
them corresponding to all the paths from which execution might flow to
them.
The bug in this case was that we were using an uninitialized map in
our calculation, resulting in a map with no GC roots at all. By the
time the map was initialized, the damage had already been done. The
solution is to treat an uninitialized map as if it has roots at all
positions so that it has no effect on the calculation until it has
been initialized with real data.
Hi,
I did some more tests with my x86 QNX Avian port and found one major problem
in Avian VM while trying to run Apache Ivy. The problem manifests as
follows:
1. MySystem::Thread X is created, during its creation pthread mutex and
conditional variable are initialized
2. Program runs for some time
3. MySystem Thread X is disposed, it's memory is freed (during garbage
collection I guess)
4. Program runs for some time
5. MySystem::Thread Y is created in exactly the same memory address as
MySystem::Thread X disposed in step 3 (I suppose that's due to the way
memory allocator works in Avian)
6. During MySystem::Thread Y creation pthread mutex and conditional variable
initialization fail silently with EBUSY. QNX documentation says it means
"The given mutex was previously initialized and hasn't been destroyed."
which is correct, because it's exactly in the same memory address as mutex
and conditional variable of MySystem::Thread X and they haven't been
destroyed during MySystem::Thread X disposal
Fortunately solution for this is easy, see the attached patch. Now Apache
Ivy works without any problems.
Regards,
Stanisław Szymczyk
Some OSes (notably, Windows CE) restrict the size of the call stack
such that recursive compilation of branch instructions can lead to
stack overflow in methods with large numbers of such instructions. In
fact, a worst-case method could even lead to overflow when the stack
size limit is relatively generous.
The solution is to convert this recursion into iteration with an
explicit stack to maintain state about alternate paths through each
branch.
This package name must match the URL protocol we use for loading
embedded resources, but OpenJDK's URL class won't tolerate underscores
in a protocol name. Also, I had not updated the names of the native
methods in avian.avianvmresource.Handler, leading to
UnsatisfiedLinkErrors when they were called.
Commit c918cbc added a reference to ensure
sun.misc.Unsafe.getLongVolatile could be implemented efficiently on
32-bit platforms, but I forgot to update bootimage.cpp to account for
it.
Commit c918cbc added this reference to ensure
sun.misc.Unsafe.getLongVolatile could be implemented efficiently on
32-bit platforms. However, I neglected to ensure the reference was
updated to point to the final class instance instead of the temporary
one used in parseClass. This led to extra memory usage and
inconsistent locking behavior, plus broken bootimage builds.
If we don't clear these references, we risk finalizing objects which
can still be reached by one of the special reference types.
It's a bit of a chicken-and-egg problem. We need to visit finalizable
objects before visiting weak references, since some of the weak
references and/or their targets may become reachable once the
finalizable objects are visited. However, that ordering means we have
no efficient way of distinguishing between objects which are reachable
from one or more normal GC roots and those which are only reachable
via the finalization queue. The solution is to clear all weak
references to finalizable objects before visiting them.
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.
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.
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.
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.
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.
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.
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>
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.
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.
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.
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.
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.
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.
