add sanity checks for makefile parameters
fix parameterization of debugger
add include paths for compiling with openjdk-icedtea7-jdk7u45_2.4.3 on darwin
add Field.getDeclaredAnnotations default method for android classpath (fixes Reflection test)
Merge pull request #254 from joshuawarner32/android-fixes

add Field.getDeclaredAnnotations default method for android classpath
Merge pull request #253 from joshuawarner32/make-fixes

Small make fixes
fix stack alignment bug in vmJumpAndInvoke

This was causing crashes on 32-bit OS X continuations=true builds.

There were two important differences between vmInvoke and
vmJumpAndInvoke: (1) vmInvoke expects its stack to be aligned on
entry, modulo the return address whereas the stack argument to
vmJumpAndInvoke is aligned without allowing for the return address,
and (2) vmInvoke pushes EBP before doing its frame allocation, whereas
vmJumpAndInvoke did not take that into account.  So in order for
vmJumpAndInvoke to allocate the exact same frame size that vmInvoke
would have when calling the same method, it needed to add an extra two
words beyond what it was already allocating.

Aside from alignment concerns, the code is not particularly sensitive
to vmJumpAndInvoke allocating a different frame size than vmInvoke,
since we store the frame pointer in a "thread local" variable:

   // remember this stack position, since we won't be able to rely on
   // %rbp being restored when the call returns
   movl   8(%ebp),%eax
   movl   %esp,TARGET_THREAD_SCRATCH(%eax)
...
GLOBAL(vmInvoke_returnAddress):
   // restore stack pointer
   movl   TARGET_THREAD_SCRATCH(%ebx),%esp

My original patch makes an equivalent change for the 64-bit changes,
but I'll leave that for after we release 1.0 since we're in
bugfix-only mode right now
Merge pull request #255 from dicej/align

fix stack alignment bug in vmJumpAndInvoke
update version to 1.0
add dockerfile for i386 cross-compiling (and testing)
add dockerfile for openjdk building (and testing)
add build command logging to ci.sh
fix test-flags definition for Windows

We need to quote a classpath with a Windows path separator (';') so it
isn't interpreted by the shell.
fix portability problem in Strings test

There was a test in Strings.java that assumed the default character
encoding was UTF-8, which is an invalid assumption on some platforms
(e.g. Windows).  This modifies the test to specify the encoding
explicitly.
Merge pull request #257 from dicej/windows

Windows fixes
Merge pull request #256 from joshuawarner32/docker

Add i386 and openjdk dockerfiles
move Runtime.freeMemory and totalMemory to builtin.cpp

This allows them to be shared between the Avian and Android class
library builds.

This commit also disables the URL test in Misc.java on Android, since
it's known to fail, and we still want to know whether the other tests
pass.
Merge pull request #259 from dicej/totalMemory

move Runtime.freeMemory and totalMemory to builtin.cpp
fix crash on exit due to order of operations bug in ~RawMonitorResource

The problem (which we've only been able to reproduce consistently with
the openjdk-src process=interpret build on Linux virtual machines) was
a race condition during VM shutdown.  Thread "A" would exit, see there
were other threads still running and thus enter ZombieState, which
involves acquiring and releasing a lock using RawMonitorResource.
Then the last thread (thread "B") would exit, wait for thread "A" to
release the lock, then shut down the VM, freeing all memory.  However,
thread "A" writes to its Thread object one last time after releasing
the lock (in ~Resource, the destructor of the superclass of
RawMonitorResource, which sets Thread::resource).  If thread "B" frees
that Thread before ~Resource runs, we end up writing to freed memory.

Thus, we need to update Thread::resource before releasing the lock.
Apparently C++ destructors run in order from most derived to least
derived, which is not what we want here.  My solution to split
Resource into two classes, one that has no destructor and another that
extends it (called AutoResource) which does hafe a destructor.  Now
all the classes which used to extend Resource extend AutoResource,
except for RawMonitorResource, which extends Resource directly so it
can control the order of operations.
Merge pull request #260 from dicej/resource-crash

fix crash on exit due to order of operations bug in ~RawMonitorResource