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
jtreg test java/lang/reflect/Array/ExceedMaxDim

This test ensures that:

1) An array with > 255 dimensions can't be created
   reflectively

2) A multi-dimensional array, where the list of dimensions
   has size 0.

JamVM failed all 3 tests!  Now fixed...

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
JVM_NewMultiArray: element class may be an array

While fixing the jtreg test that tested creating via reflection arrays of
256 dimensions, I noticed that there was nothing stopping the element class
actually already being an array (rather than a base element).  Writing a
test program confirmed this.  I didn't consider this case when originally
writing the code, and so the test program didn't work with JamVM.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Minor correction to TRACE line

At some point I renamed some variables to have a consistent style
but forgot to change one instance in a TRACE.  This didn't cause
a problem until I actually tried to turn tracing on.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
JSR 292: Fix CallStaticInitOrder jtreg test

A recent change to resolveMethodHandle made it call the resolveXXX
functions rather than peeking the referenced entry (as it may
already be resolved).  This had the side-effect of initialising
the method's defining class.  This is because resolveMethod
always initialised the class.  It previously was only used when
executing an invoke bytecode.  For static invokes, initing is required,
and for non-static invokes it was a no-op.

Fixed by moving the call to initClass from resolveMethod to the
invoke static rewriter.  This means it's only initialised when we
first execute the bytecode.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
JSR 292: remove java/lang/invoke/MagicLambdaImpl

Previously the MagicLambdaImpl class gave special access permissions to the
auto-generated method handle adapters.  After updating to the head of OpenJDK
8 last week, I discovered the class had been removed - this caused JamVM to
fail during initialisation.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
JSR 292: findInvokeDynamicInvoker fix exception handling

In the code that intercepts LinkageErrors we need to check to see if
the thrown exception is either a BootstrapMethodError or LinkageError.
However, the code passed the exception object into the isSubClassOf
checks rather the exception class.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Forgot to update the copyright date.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
JSR 292: anonymous classes should use host_class permissions

Anonymous classes are associated with a host class which they
may need to access.  We therefore must store the host class and
use the host class when performing access checks.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Do not initialise the class when resolving a field

A recent commit changed resolution of methods so that the declaring
class was no longer initialised - this was moved into the interpreter
and only done on first execution of a static method (as per the spec).
A similar issue exists with fields, although the failing jtreg method
handle test didn't fail (as it doesn't handle fields).

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
JSR 292: anonymous class resolution to itself

Anonymous classes are not recorded in the class loader tables.
When resolving a class from a class, we looked up the class by
name in the referring classes class loader.  However, this fails
when the class is an anonymous class and it is resolving a
symbolic reference to itself.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Optimise ClassBlock structure

I've known for some time that the ClassBlock structure, due
to being developed initially on a 32-bit machine contained
some redundant padding on a 64-bit machine (because of a mixture
of ints and pointers).

Rearrange structure to pack similar sized fields together to
minimise padding.  This saves 24 bytes on a 64-bit machine.

The rationale for doing this is to hide the extra field
host_class - this is redundant for most classes.  Best solution
is to develop a way to only add this for anonymous classes, but
for now, reducing the size of ClassBlock means the addition
doesn't add to the overall size.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Further optimisation of ClassBlock

The space removed in the previous change was mostly applicable
to 64-bit machines. However, several fields are mutually
exclusive between array and non-array classes.  Put these into
unions.  This overlaps two fields which saves 8 bytes on a
32-bit machine.  On a 64-bit machine, it also saves 8 bytes
as the overlapped int field is replaced by padding so it doesn't
reduce the overall size.

This is the optimal ClassBlock structure.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>