Add missing REF_TO_OBJs for references passed from JNI

In JamVM, JNI references are real direct object references
and not handles.  However, the bottom bits are tagged to
record the reference type (Global, Weak, etc.).  This
means the bits must be masked off whenever a reference
is passed from a JNI method and is used within the VM.

Somehow, I forgot to mask the bits off when a reference
is returned from a JNI method, and also when a reference
is stored into an object field or an array.  This has
been present since the start of 2010, so I'm surprised
it has taken so long to show up!

The error showed up with Qt Jambi, which is a wrapper
which enables Qt to be used from Java (crash reported
by Xerxes Ranby).

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Ref return values from JNI methods need to handled specially

When constructing the JNI simple sig, ref return values
must be handled specially (tag bits masked off via
REF_TO_OBJ).  Previously, they were treated the same as
ints, and converted to the simple sig char 'I'.

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

Reference return values are now handled differently to
I, and so the JNI stubs need to be regenerated (previous
sigs that may have mapped to the same stub will now
have separate stubs).

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Update stubs generator to handle ref returns

Reference return values from JNI methods must
have their bottom bits masked off via
REF_TO_OBJ.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Rewritten machine dependent i386 simple sigs

Ref return values from JNI methods now need to
be treated differently to int results.

Also taken opportunity to improve simple sigs
on i386.  Previously, 64-bit values were converted
to two 32-bit integer quantities (i.e. II).

However, it makes more sense to convert pairs
of 32-bit values into a single J simple sig
char, representing a 64-bit quantity.  This
still enables multiple signatures to map to
a single stub, but leads to much shorter
simple sigs, which will improve performance
(especially when using libffi).

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Generate machine-dependent stubs for i386.

Because all parameters are passed on the stack,
a much smaller number of stubs are necessary
on i386 to cover the same set of signatures as
the "generic" JNI stubs.  For this reason,
i386 is the only platform that has machine-
dependent stubs (all platforms can support
machine dependent stubs, but other platforms
offer no advantage over the generic stubs).

However, although machine-dependent stubs are
on by default for i386, I never bothered to
generate them (it previously had empty stub
tables)!  This was mainly because I believed
nobody really still used i386 instead of
amd64.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Update copyright message shown on -version

Updated to also include 2012.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
In TRACE, use %p format specifier instead of 0x%x

JamVM was initially written on 32-bit machines, and I used
0x%x to print pointers.  However, this doesn't work on 64-bit
machines, so I updated all format strings to use %p.  For
some reason thread.c was still using 0x%x.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
When suspending, ignore detached threads that have died

When signalling threads to suspend, if pthread_kill returns
ESRCH this indicates that the thread has died.  This can only
occur when an external thread has been attached to the VM
via JNI and it has exited without detaching.  Although it
is a user error, it will deadlock the suspension code as it
will hang waiting for the thread to suspend.  Set the state
to BLOCKING, to ignore the thread. Note, no attempt is made
to clean-up the error; the thread will still appear to be
"live" (as with Hotspot).  We simply stop the thread from
hanging the VM.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Add extra compatibility options

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Don't use lwsync if it isn't supported

A lwsync (lightweight sync) instruction is used when unlocking a
thin lock.  The lwsync is sufficient to satisfy the Java Memory
Model, but is much cheaper than a full sync.  However, some
modern PowerPC cores do not support lwsync, for example, e500v2
(reported by Darcy Watkins).

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Changes for Raspbian (Raspberry Pi)

Debian, when producing a new high-performance distribution
for modern ARM cores, decided to introduce a new "architecture"
called armhf (as opposed to armel).  This supports VFP for
floating-point, and in addition uses floating-point registers
for passing floating-point arguments (hence hf for hard-float).

For armhf, they set a minimum requirement of ARMv7-A and VFPv3-D16.
Unfortunately, the Raspberry Pi does not meet this (being ARMv6 +
VFPv2).  So Raspbian is a recompile of Debian Wheezy armhf for
ARMv6 + VFPv2.

Unfortunately, when I ported JamVM to hard-float ABI, I decided
to use Thumb2.  This was fine, as armhf must support Thumb2.
However, this decision means JamVM doesn't work when compiled
for Raspbian as it contains ARMv7-A instructions.  To make it
worse, I initially implemented hard-float ABI in ARM mode, but
decided to switch to Thumb2 as it was a good opportunity to use
the tbb instruction!

As the Thumb2 implementation will have better performance on ARMv7-A
cores than the ARM version, I have decided to also include the
ARM version which will be used when ARMv7-A isn't supported (i.e.
Raspbian).

In addition, I have updated the code to use ldrex/strex for atomic
operations instead of swp on ARMv6.  Previously, ldrex/strex was
only used on ARMv7-A, but swp is also deprecated on ARMv6.  I
previously only did it for ARMv7-A because of concerns that some
ARMv6 implementations didn't implement ldrex/strex properly
(e.g. OMAP2).  I can no longer find any evidence for this.  Also,
OMAP2 is now pretty ancient, and I prefer to fix it for the buggered
implementations, if and when a problem occurs, rather than nobbling
it for all ARMv6.

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

Forgot to add 2012 when I modified the file...

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

Error in comment caused by erroneous match in find/replace
when changing ip register usage.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
Make JamVM work with latest OpenJDK 7

The latest OpenJDK 7 has two changes which break JamVM:

1) A new function needs to be defined JVM_SetNativeThreadName.
   The current implementation doesn't do anything.

2) java.lang.String has been changed to not use shared char
   buffers.  This means strings no longer have the count or
   offset fields.  VMs normally have embedded knowledge of
   the internal structure of string objects to enable fast
   construction and access.  So JamVMs internal routines
   need to be updated to reflect the changes.  However, GNU
   Classpath still uses shared buffers, as does OpenJDK 6.
   This means the changes are not split cleanly along
   classlib boundaries.  I have instead resorted to the use
   of an ifdef (SHARED_CHAR_BUFFERS).  I normally hate ifdefs
   in code, but for the moment, this seems to be the cleanest
   solution.

As a result of the java.lang.String changes, the configure
--with-java-runtime-library has changed.  Instead of the
supported values simply being gnuclasspath and openjdk, we now
need to distinguish which OpenJDK, so the values are now
gnuclasspath, openjdk6 and openjdk7.  For the first two,
SHARED_CHAR_BUFFERS is defined, but not for openjdk7.

Signed-off-by: Robert Lougher <rob@jamvm.org.uk>
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>