JSR 292: bootstrap method args error handling

When I wrote the bootstrap method args code I forgot that
resolveSingleConstant does not return NULL on error.  Previously,
the way to tell if an error had occurred in one of the resolveXXX
functions was to check exceptionOccurred.  However, this is
(potentially) slow, so the code was changed so that in most
cases NULL was also returned.  However, this doesn't apply to
resolveSingleConstant, as the return value is an opaque uintptr_t,
and it can potentially return 0 in a non-error situation (e.g.
resolving a CONSTANT_Integer).

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
JSR 292: MethodHandle constant-pool refs may be resolved

A method handle constant-pool entry contains the index of the
referenced entry in the constant-pool and the reference kind (the
bytecode behaviour).  The referenced entry can be a field, a method
or an interface method.  The class, name and type of the entry is
passed up to the JSR 292 runtime, which links it and returns a
MethodHandle.

For some unknown reason, when I wrote the code initially, I
resolved the class, and peeked the name and type from the referenced
entry (although there may be different entries, they're all stored
the same).  I was probably following the spec too closely.  The
Java code also simply calls back into the VM to resolve the entry
so maybe I was avoiding doing resolution twice.

However, I forgot the entry may have been resolved from a different
path.  In this case, peeking a resolved entry gives wrong indexes,
and the code fails in a random way.

Fix is to resolve the entry via the correct resolveXXX function and
then obtain the class, name and type from the resolved entry.  The
reference kind is used to determine the correct resolveXXX function to
call.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Fix race-condition in constant-pool resolution code

The constant-pool resolution code is lock-less.  Instead
it relies on the correct ordering of reads/writes, which it
ensures using memory-barriers.

Recently I noticed an intermittent crash with Dacapo xalan benchmark
which I tracked down to the resolution code.  Recent versions of gcc
are re-arranging some loads which break the required ordering.

For example, in the following code, the load for the re-check of
the CP_TYPE must be done after the load for the name_idx (because
if the type is still the same, we know the name_idx is correct as
it was read before).

        case CONSTANT_Class: {
            char *classname;
            int name_idx = CP_CLASS(cp, cp_index);

            if(CP_TYPE(cp, cp_index) != CONSTANT_Class)
                goto retry;

However, gcc had re-ordered the loads so that the load for the name_idx
was done after that for the type.  This means there is a small race-
condition between checking the type and loading the name_idx where
the entry could be resolved by another thread.  In this case, the loaded
idx would be wrong.

Simple fix is to insert an extra memory barrier which prevents the
re-ordering.  Although a compile barrier would also do this, a memory
barrier has always been missing here, as some memory architectures
may re-order the loads even if they were executed in the correct order.
classlibMarkThreadTerminated should return Object*

A couple of checkins ago, I fixed a deadlock in thread deletion.
To fix it, classlibMarkThreadTerminated returns a "keep-alive"
object (only needed for GNU Classpath).  This isn't actually
used - all that's done is a reference is kept to it.  However,
the return type should be Object* rather than void*.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
classlibMarkThreadTerminated should return Object*

A couple of checkins ago, I fixed a race in thread deletion.
To fix it, classlibMarkThreadTerminated returns a "keep-alive"
object (only needed for GNU Classpath).  This isn't actually
used - all that's done is a reference is kept to it.  However,
the return type should be Object* rather than void*.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
OpenJDK: Fix Local/Anonymous class checks

According to JVM spec 4.8.6 a class must have an EnclosingMethod
attribute if and only if it is a local or an anonymous class.

In constrast, a nested or inner class has a declaring class
specified in the InnerClasses attribute.

The enclosing class is therefore either the enclosing class from
the EnclosingMethod, or the declaring class from the InnerClasses
attribute.

When implementing this with GNU Classpath, I handled it by simply
setting the enclosing class to the declaring class when parsing the
InnerClasses attribute.  GetEnclosingClass then simply returned the
enclosing class (which could be the declaring class).

When implementing GetEnclosingMethodInfo on OpenJDK, it simply
returned the enclosing class and any enclosing method.  Unfortunately,
OpenJDK uses the presence of MethodInfo to tell if a class is a local
or anonymous class (as according to the spec, only these classes have
an EnclosingMethod attribute).  But because enclosing class is
set to the declaring class, nested or inner classes appear to have
MethodInfo, and therefore appear to be a local/anonymous class.
With GNU Classpath/JamVM, the anonymous/local class check
is implemented in a different way, and doesn't use the absence
of an enclosing class.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
GNU Classpath: typo in getEnclosingMethodObject

While modifying getEnclosingMethod, noticed an obvious typo in
getEnclosingMethodObject.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Merge branch 'master' of ssh://git.berlios.de/gitroot/jamvm