don't create '1' file from docker/build.sh
fix arm compiler abort
Merge pull request #280 from joshuawarner32/master

Fix arm compiler abort
rename platform=darwin -> platform={ios,macosx}, fix ios simulator build
update README.md with darwin->{macosx,ios} rename
remove redundant PROTECT usage

This was causing crashes at GC time since we ended up visiting the
same reference twice in a single GC cycle.
Merge pull request #282 from dicej/protect

remove redundant PROTECT usage
fix case of JNIEnv::FindClass called from JNI_OnLoad

If an JNI_OnLoad implementation calls FindClass when using the OpenJDK
class library, the calling method on the Java stack will be
ClassLoader.loadLibrary.  However, we must use the class loader of the
class attempting to load the library in this case, not the system
classloader.

Therefore, we now maintain a stack such that the latest class to load
a library in the current thread is at the top, and we use that class
whenever FindClass is called by ClassLoader.loadLibrary (via
JNI_OnLoad).

Note that this patch does not attempt to address the same problem for
the Avian or Android class libraries, but the same strategy should
work for them as well.
Merge pull request #281 from joshuawarner32/darwin-platform-reorg

rename platform=darwin -> platform={ios,macosx}, fix ios simulator build
only generate crash dump if faulting instruction is in main executable

The VM should only assume it should/will crash if it triggers an
e.g. EXCEPTION_ACCESS_VIOLATION itself.  In other words, if some
non-VM code triggers such an event, the VM should let that code handle
it as appropriate.  Avian already does this properly, but it also
generates crash dumps for each event encountered if avian.crash.dir is
set, regardless if whether the VM triggered it or not.  This can be a
problem if such events are generated frequently -- a full memory dump
takes a long time to write and a lot of disk space.

Ideally, we'd have some reliable way to determine whether the faulting
instruction pointer belongs to the VM or not, but the closest thing I
could come up with was to compare the module that owns the address
with the module representing the main executable.  This can lead to
both false positives (e.g. application code in the main executable
which is not part of the VM) and false negatives (e.g. when the VM is
loaded from a library instead of the main executable), but it's still
an improvement over the status quo.

Even better would be to ensure that the VM's exception handler is the
very last one to run, so that we know for sure that the error is
unrecoverable and thus it is appropriate to do a full memory dump.
Merge pull request #284 from dicej/dump

only generate crash dump if faulting instruction is in main executable
fix unused declaration/definition warnings from GCC 4.9
Merge pull request #285 from dicej/warnings

fix unused declaration/definition warnings from GCC 4.9
allow stress and stress-major as valid mode= settings in the makefile (note: all tests fail in both modes)
use stress-major consistently in makefile
Merge remote-tracking branch 'remotes/dicej/findclass-onload'
Merge pull request #286 from joshuawarner32/allow-stress-builds

allow stress and stress-major as valid mode= settings in the makefile
fix JNIEnv::FindClass calls from JNI_OnLoad for all supported class libraries

This also fixes the some Android build rot and updates the version of
OpenSSL used.
Merge pull request #283 from dicej/findclass-onload

fix case of JNIEnv::FindClass called from JNI_OnLoad
only wrap Exceptions in ExceptionInInitializerErrors, not Errors