add basic URLClassLoader implementation
Merge branch 'master' of github.com:ReadyTalk/avian
classpath: Closeable & Flushable
classpath: j.l.{Integer,Long}.to{Octal,Binary}String

Offer support for toOctalString and toBinaryString in Integer and Long.
classpath: java.nio.ByteOrder

Used by jruby.
(Not saying I'm gonna implement String.format :)
Merge pull request #19 from pcarrier/classpath

classpath: java.nio.ByteOrder
Accept M and K suffixes for memory sizes like the java command
Merge pull request #20 from csoren/master

A simple fix to accept upper case size suffixes for the -Xm parameters
Added new embed utility for Windows
Merge branch 'master' of git://github.com/ReadyTalk/avian
Fix for C++ compile error
Compile fix for GCC 4.7.2 in C++11 mode
fix pthread mutex and condition leak

Hi,

I did some more tests with my x86 QNX Avian port and found one major problem
in Avian VM while trying to run Apache Ivy. The problem manifests as
follows:

1. MySystem::Thread X is created, during its creation pthread mutex and
conditional variable are initialized
2. Program runs for some time
3. MySystem Thread X is disposed, it's memory is freed (during garbage
collection I guess)
4. Program runs for some time
5. MySystem::Thread Y is created in exactly the same memory address as
MySystem::Thread X disposed in step 3 (I suppose that's due to the way
memory allocator works in Avian)
6. During MySystem::Thread Y creation pthread mutex and conditional variable
initialization fail silently with EBUSY. QNX documentation says it means
"The given mutex was previously initialized and hasn't been destroyed."
which is correct, because it's exactly in the same memory address as mutex
and conditional variable of MySystem::Thread X and they haven't been
destroyed during MySystem::Thread X disposal

Fortunately solution for this is easy, see the attached patch. Now Apache
Ivy works without any problems.

Regards,
Stanisław Szymczyk
Merge remote-tracking branch 'csoren/master'
fix Windows cross-compile build
fix MSVC build regression
fix stack mapping bug for try blocks containing jsr/ret instructions

In order to calculate the initial stack map of GC roots for an
exception handler, we do a logical "and" of maps across all the
instructions contained in the try block for that handler.  This is
complicated by the presence of jsr/ret instructions, though, because
instructions in a subroutine may have multiple maps associated with
them corresponding to all the paths from which execution might flow to
them.

The bug in this case was that we were using an uninitialized map in
our calculation, resulting in a map with no GC roots at all.  By the
time the map was initialized, the damage had already been done.  The
solution is to treat an uninitialized map as if it has roots at all
positions so that it has no effect on the calculation until it has
been initialized with real data.
print more of the stack map when DebugFrameMaps is enabled
implement JNI reflection methods

These include FromReflectedMethod, ToReflectedMethod,
FromReflectedField, and ToReflectedField.
Changed reinterpret_cast to static_cast