Do not put version number in libjvm.so SONAME

In OpenJDK the libjava.so shared object has a dependency on libjvm.so.
Hotspot's libjvm.so SONAME doesn't have a version number but JamVMs
does (created via libtool).  If JamVM is being built as an additional
VM, libjava.so is linked against Hotspot's libjvm.so, and we end up with
a library which can't find JamVMs libjvm.so.  However, it works if
JamVM is the only VM being built, as libjava.so is linked against
JamVMs libjvm.so.

Simple fix is to stop libtool versioning the SONAME with -avoid-version.
Patch provided by Xerxes Ranby and Matthias Klose.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
First commit of OpenJDK8 JSR292 support

This is still quite a way from being complete, but I'm happy enough
with progress to believe that the implementation is along the right
lines.  At present it can run 11 out of the 17 jtreg invoke tests:

Passed: java/lang/invoke/6987555/Test6987555.java
Passed: java/lang/invoke/6991596/Test6991596.java
Passed: java/lang/invoke/6998541/Test6998541.java
Passed: java/lang/invoke/7157574/Test7157574.java
Passed: java/lang/invoke/AccessControlTest.java
FAILED: java/lang/invoke/CallSiteTest.java
Passed: java/lang/invoke/ClassValueTest.java
FAILED: java/lang/invoke/InvokeDynamicPrintArgs.java
Passed: java/lang/invoke/InvokeGenericTest.java
FAILED: java/lang/invoke/JavaDocExamplesTest.java
Passed: java/lang/invoke/MaxTest.java
FAILED: java/lang/invoke/MethodHandlesTest.java
Passed: java/lang/invoke/MethodTypeTest.java
Passed: java/lang/invoke/PermuteArgsTest.java
Passed: java/lang/invoke/PrivateInvokeTest.java
FAILED: java/lang/invoke/RicochetTest.java
Error:  java/lang/invoke/ThrowExceptionsTest.java
Test results: passed: 11; failed: 5; error: 1

Most of these failures are due to invokedynamic and its associated class
file changes not yet being implemented.  The implementation is currently
sufficient to bootstrap the Java-based JSR292 "engine", and run
invokeExact, etc.

Apart from invokedynamic, the other bit that is missing is an implementation
of an "injector" framework.  OpenJDK8 has removed private VM fields from
various classes, and instead uses injection to add the fields at runtime.

On one hand, this is very useful as it means JamVM no longer has to fit in
with the hotspot specific fields.  But currently it means there's no
VM fields for JamVM to use at all.  For now, I've hacked the classes to
add them, but I need to implement an equivalent field injector before
I can make a release.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Implement invokeExact with the indirect interpreter

Make the ancient switch-based interpreter work with invokeExact, etc.
This has the one and only advantage that it is _much_ easier to debug
than the "code-copying JIT".  Should have done this ages ago, as
debugging invoke problems with JITted code has been very time
consuming.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Further OpenJDK JSR 292 work

Basic support for invokedynamic implemented.  JSR 292 jtreg
test CallSiteTest now passes (total now stands at 12 passed,
4 failed, 1 error).

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Two more JSR 292 jtreg tests passing

Yesterday 4 tests failed, with 1 error (timeout).  Two additional
tests are now passing, and the error is now a fail (which is
an improvement - today while fixing the other tests, found
stack unwinding could get in a loop - this is probably also the
reason for the timeout on this test).

jtreg -testjdk:$PRODUCT_HOME -verbose:summary -timeout:10 invoke
Passed: java/lang/invoke/6987555/Test6987555.java
Passed: java/lang/invoke/6991596/Test6991596.java
Passed: java/lang/invoke/6998541/Test6998541.java
Passed: java/lang/invoke/7157574/Test7157574.java
Passed: java/lang/invoke/AccessControlTest.java
Passed: java/lang/invoke/CallSiteTest.java
Passed: java/lang/invoke/ClassValueTest.java
Passed: java/lang/invoke/InvokeDynamicPrintArgs.java
Passed: java/lang/invoke/InvokeGenericTest.java
FAILED: java/lang/invoke/JavaDocExamplesTest.java
Passed: java/lang/invoke/MaxTest.java
FAILED: java/lang/invoke/MethodHandlesTest.java
Passed: java/lang/invoke/MethodTypeTest.java
Passed: java/lang/invoke/PermuteArgsTest.java
Passed: java/lang/invoke/PrivateInvokeTest.java
Passed: java/lang/invoke/RicochetTest.java
FAILED: java/lang/invoke/ThrowExceptionsTest.java
Test results: passed: 14; failed: 3

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Merge branch 'master' of ssh://git.berlios.de/gitroot/jamvm
JSR 292 work: all jtreg tests now pass

jtreg -testjdk:$PRODUCT_HOME -verbose:summary -timeout:10 invoke
Passed: java/lang/invoke/6987555/Test6987555.java
Passed: java/lang/invoke/6991596/Test6991596.java
Passed: java/lang/invoke/6998541/Test6998541.java
Passed: java/lang/invoke/7157574/Test7157574.java
Passed: java/lang/invoke/AccessControlTest.java
Passed: java/lang/invoke/CallSiteTest.java
Passed: java/lang/invoke/ClassValueTest.java
Passed: java/lang/invoke/InvokeDynamicPrintArgs.java
Passed: java/lang/invoke/InvokeGenericTest.java
Passed: java/lang/invoke/JavaDocExamplesTest.java
Passed: java/lang/invoke/MaxTest.java
Passed: java/lang/invoke/MethodHandlesTest.java
Passed: java/lang/invoke/MethodTypeTest.java
Passed: java/lang/invoke/PermuteArgsTest.java
Passed: java/lang/invoke/PrivateInvokeTest.java
Passed: java/lang/invoke/RicochetTest.java
Passed: java/lang/invoke/ThrowExceptionsTest.java
Test results: passed: 17

While running the tests there has always been the possibility of
discovering some major hole in my understanding.  Assuming the jtreg
tests are comprehensive, this point should now be passed.

Having said that, there is still a fair amount of work remaining. Not
least the way in which I have had to play about with the default Java
stack settings (some of the tests do nasty things like creating deeply
nested calls and catching StackOverflow).  It also won't run with
"vanilla" OpenJDK, as the field injection stuff is still missing.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Dummy implementation of sun.misc.Perf natives

The OpenJDK 7 and OpenJDK 8 sources contain various calls
to sun.misc.Perf for performance profiling of class-loading.
Whether this is left-over debug code or is intentional is
not clear.  However, this causes JamVM to fail as it doesn't
implement the native methods for sun.misc.Perf.

IcedTea 7 contains a patch to remove these calls to enable
JamVM to run.  But this doesn't help when running with
"vanilla" OpenJDK 8, which I'm using for the JSR 292 work
(no IcedTea version for OpenJDK 8 exists, that I'm aware off).

Hacking the sources to remove these calls everytime I get
a new version is a huge pain-in-the-ass.  So this is a dummy
implementation, sufficient to get the sources to run without
hacking them.

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

I added two fields to MemberName for VM use: vmtarget and
vmindex (copying HotSpot).  In the end, I only need one
field to hold a pointer to the underlying MethodBlock or
FieldBlock.

I may still need an extra field, but I dislike cruft, so
for now I'm removing the field.  Of course, finally, VM
fields should be inserted by a "field injector" framework...

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Set anonymous class protection domain

Anonymous class protection domain should be set to the
host class protection domain.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Yet more JSR 292 jtreg tests

Now that all the jtreg tests _were_ passing, I thought I'd
update my sources (the ones I have been using are several months
old).  As OpenJDK 8 is still in development, I was half expecting
rewrites, major changes, etc.  Turns out that everything I've
done is still OK, but several new jtreg tests have been added.
JamVM succeeded in failing them all...  Very depressing - back to
the slog of debugging.

New Tests:

7196190/ClassForNameTest
7196190/GetUnsafeTest
7196190/MHProxyTest
BigArityTest
lambda/LambdaAccessControlTest
lambda/LambdaAccessControlDoPrivilegedTest

Removed Tests:

MaxTest

ClassForNameTest/MHProxyTest were failing the same way.  First
I forgot to set the protection domain on unsafe defined anonymous
classes (checked in already).  Much more tricky, however, was the
failures related to stack-walking/security.

The frames for intrinsics already do not appear, as they are
overwritten by the frame for the real target.  However, in addition
to the intrinsics, certain frames of the auto-generated bytecodes
should not appear (compiled LambdaForms).  These are marked via
annotations.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Garbage collector changes for JSR 292

I knew this would bite me one of these days.  While implementing JSR
292 I never bothered to do the GC changes to mark and thread the
additional resolved entries in the constant pool (preferring to
wait until the code was less experimental).  Turns out the
BigArityTest was failing due to a ClassCastException in the method
handle invoker checking code.  The appendix parameter was no
longer a MethodType!  This was the result of heap compaction; the
appendix object had been moved but the reference to it reachable
from the constant pool had not been updated.

The jtreg test status is now 19 passed, with 3 failures.  I've had a
quick look at GetUnsafeTest.  This tests whether sun.misc.Unsafe is
accessible "reflectively", i.e. via Class.forName, etc. (security
policy is probably involved as well).  I don't consider this a "normal"
code stopper so it's not high on my priority list to fix.  Next
ones to look at are the Lambda failures.

Passed: java/lang/invoke/6987555/Test6987555.java
Passed: java/lang/invoke/6991596/Test6991596.java
Passed: java/lang/invoke/6998541/Test6998541.java
Passed: java/lang/invoke/7157574/Test7157574.java
Passed: java/lang/invoke/7196190/ClassForNameTest.java
FAILED: java/lang/invoke/7196190/GetUnsafeTest.java
Passed: java/lang/invoke/7196190/MHProxyTest.java
FAILED: java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java
FAILED: java/lang/invoke/lambda/LambdaAccessControlTest.java
Passed: java/lang/invoke/AccessControlTest.java
Passed: java/lang/invoke/BigArityTest.java
Passed: java/lang/invoke/CallSiteTest.java
Passed: java/lang/invoke/ClassValueTest.java
Passed: java/lang/invoke/InvokeDynamicPrintArgs.java
Passed: java/lang/invoke/InvokeGenericTest.java
Passed: java/lang/invoke/JavaDocExamplesTest.java
Passed: java/lang/invoke/MethodHandlesTest.java
Passed: java/lang/invoke/MethodTypeTest.java
Passed: java/lang/invoke/PermuteArgsTest.java
Passed: java/lang/invoke/PrivateInvokeTest.java
Passed: java/lang/invoke/RicochetTest.java
Passed: java/lang/invoke/ThrowExceptionsTest.java
Test results: passed: 19; failed: 3

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
JSR 292 Lambda access control jtreg tests

The two Lambda access control tests were fairly easy to fix.
Turns out there's another magic accessor class which must be
given access...

All that's now remaining is the GetUnsafeTest which I said
I wasn't bothering with.  Look to see how easy it is to fix.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Minor tidy-up of class-loading code

While looking into the GetUnsafeTest failure, noticed a minor
readability improvement.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Very simple field injection framework

Currently there's only one field that needs to be injected
into one class (java.lang.invoke.MemberName).  Plus of
course it's not needed for GNU Classpath (as the Java classes
are part of JamVM).  For this reason I have made the
"framework" as light as possible, and it will be entirely
optimised out for GNU Classpath.  However, it is a proper
framework, and extra classes/fields can be added as needed.

While editing class.c for fun on an old VT220, it was obvious
that many lines still wrapped at 80 columns despite several
passes over the file in the past to correct it.  Finally
fixed the file, which involved minor rewrites in several
places to remove old code embedded within ifs and joined
together with &&.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Fixed 3 "makes integer from pointer" warnings

Storing into an object  field of size uinptr_t, but the values are
pointers.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Fixed last 2 warnings (in interp.c)

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Update copyright to 2013

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Remove trailling spaces at end of lines

Some lines had trailling spaces at the end of them.  Shown
by syntax highlighting on a VT220, as it uses underlining.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
JSR 292 invokedynamic for direct-threaded interpreter

Implemented invokedynamic for direct-threaded and inline-
threaded (aka code-copying JIT) interpreters.  Previously
invokedynamic only worked on indirect-threaded versions of
the interpreter (development was done using the basic switch
implementation as this is easier to debug).

Changes are minor, as invokedynamic follows the same pattern
as existing invokeXXX opcodes.

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