rspec refactor for ffi to use expect inspite of should to make it better
Remove several locks involved in thread mail and lifecycle.

The deadlock reported in #1015 was caused by RubyThread#dispose
and Thread#kill logic (RubyThread#kill) acquiring the same two
locks in opposite order. dispose first acquired the RubyThread
monitor, in order to read and write volatile state, and then
acquired the ThreadService monitor without releasing RubyThread in
order to unregister the RubyThread object. kill acquired the
ThreadService monitor and then attempted to acquire the RubyThread
monitor in order to deliver the kill event.

As it turned out, the "mail" field on RubyThread was the primary
actor triggering the use of synchronization, and much of that
synchronization was not necessary. The removal of the thread from
ThreadService did not need to be synchronized. The dispose and
receiveMail methods did not need to be synchronized if the mail
slot was made into an atomic reference. The deliverEvent method
did not need to be synchronized for any reason.

I made the appropriate changes to turn mail into an atomic
reference, avoid keeping the RubyThread lock when calling into
ThreadService to remove the RubyThread, and remove locks that
became irrelevant once mail became atomic.

Fixes #1015.
Merge branch 'master' of jruby.org:jruby
Merge pull request #977 from rajcybage/more_rspec_fix

rspec refactor for ffi to use expect inspite of should to make it better
cleanup build config [skip ci]
do not declare jars in gemspec [skip ci]
not needed anymore since https://github.com/jnr/jnr-ffi/commit/1f7965393b907af1ec799b22604e99596323a6cf [skip ci]
Windows installer works on binary zip from mvn -Pdist as extra step
use released jnr-posix artifact now [skip ci]
Fix jffi.boot.library.path in jruby.bash
Better error when JCE unlimited crypto is not available.

Related to #919
Related to JRUBY-7093
Merge branch 'master' of jruby.org:jruby
Mangle filenames in block descriptors so they'll always parse.

Fixes #961.
GH #944: Add RVM step to build instructions
Update krypt to match gem contents.
Make Thread#backtrace a bit more thread-safe.

The original NPE for #406 was due to the thread not having started
running yet; its "context" reference was null. I added logic to
check for that and not try to produce a backtrace.

In addition, I discovered that the building of the trace was also
not threadsafe, since the "backtrace" and "backtraceIndex" fields
in ThreadContext could be updated at the same time by the original
thread. My changes here should make it less likely that backtrace
building will walk off the end of the "backtrace" array, but there
will still be cases where the index and the array get out of sync
and the backtrace contains a couple bogus lines. It is unclear
to me whether we should forcibly prevent the target thread from
updating these fields while the backtrace-generating thread is
generating, since it would surely introduce overhead into the
normal backtrace updating process.

Fixes #406.
Fix deprecation warnings in a few regression specs.
Update to RubyGems 2.1.4

`jruby -S gem update --system` followed by `git checkout -- bin/jgem`
Add logging to show the operation of the JIT cache.
Disable the JIT cache when invokedynamic is enabled.

This fixes #1005.

Here's a reproduction that I'll use to discuss the problem:
https://gist.github.com/headius/6599215

So the issue here is how the @@ variables are accessed.

@@var class vars are loaded using the current static scope (lexical scope from
parser) which contains a reference to the surrounding class at the time the
code was instantiated. The scope itself gets stored either in the AST
(interpreter) or in the AbstractScript associated with the compiled code. When
retrieving an class variable, we first acquire a reference to the scope and
then look up the variable against the class it references.

In the non-indy compiler, the scope is retrieved each time from the
AbstractScript object associated with the currently executing code. This
requires hopping through a couple levels of indirection, but if the same JVM
bytecode is used with different logical code bodies, they continue to work
properly since they always go to the AbstractScript object.

The situation with indy is a bit different.

In order to make it possible for the JVM JIT to fold away repeated accesses of
the same scope, we permanently cache the scope at the physical call site. The
call site is unique to a given loaded piece of bytecode, so if the same loaded
bytecode gets shared across logically different code bodies, we can end up
using the scope associated with a previously jitted version of the same code.
That's what's happening here.

In my example, the class variable accessors for @@bar are eval'ed into multiple
classes, but to our JIT cache they look identical since they don't include
anything to make them appear unique for each class. This means we use a single
loaded version of the bytecode and all subclasses end up sharing the same
bytecode. This means, in turn, they share a single call site...and the hard
caching of the scope ends up going to the first method to JIT. In this case,
that means FooAlpha's bar and @@bar are used rather than FooBeta's when the
latter's bar methods JIT.

The core problem here is the caching for JVM bytecode/class for a JITed method
does not have a sufficiently unique key to represent identical bytecode that
has different runtime artifacts attached to it...like static scope.

There are a few ways to fix this:

Modify the static scope logic in our invokedynamic backend to not permanently
cache the scope. This would work, but would cause repeat accesses of that scope
to go through full indirection every time. It may require also fixing other
values looked up from scope like constants...and losing JIT value folding for
constants would be a terrible step backward.

Modify the key for the JIT cache to include additional information about the
lexical scoping structures being used. This may require some help from the
parser, since at the moment there's no way to distinguish two StaticScope
objects other than by their hashcodes. Adding the scope hashcodes to the key
would be a quick way to fix this without completely breaking caching, but it
may be that bytecode caching in the presence of invokedynamic will bite us in
other ways down the road.

Disable JIT caching in the presence of invokedynamic. The feature was
originally added when it was assumed that all users would always need to run
multiple copies of the same JRuby application in a given JVM, where we would
potentially crumble under the load of all those mostly-identical JITed methods.
However, applications have been trending toward a single JRuby instance across
all threads, memory has been getting cheaper, and Java 8 eliminates the permgen
we were originally so concerned about.

I'm leaning strongly enough toward the third option that I'm going to go with
it for now. So many of our uses of invokedynamic require the loaded code and
call sites to be as unique as the logical methods they represent, and I can
think of several other places where the current caching could (and maybe
already is) biting us. This will potentially mean JRuby apps running under indy
load more code, but in actuality it will almost exclusively affect
multi-instance applications. Provide the JVM with more memory or run a single
instance.