Accept Encoding object for Encoding.compatible?

With this change, the following calls are supported:

    Encoding.compatible?(Encoding.find("UTF-8"),
                         "String".force_encoding("UTF-8"))
    # => #<Encoding:UTF-8>

    Encoding.compatible?("String".force_encoding("UTF-8"),
                         Encoding.find("US-ASCII"))
    # => #<Encoding:UTF-8>

    Encoding.compatible?(Encoding.find("UTF-8"),
                         Encoding.find("US-ASCII"))
    # => #<Encoding:UTF-8>
Add const_get to java package Fixes #435
[IR] Breaks and non-local returns handled entirely via IR instrs.

* Removed last bits of special case handling of breaks and
  non-local returns from the interpreter by adding global exception
  handling in methods (those that receive nonlocal returns) and
  all closures (for stopping uncaught breaks in lambdas).  Since
  there is no syntactic/lexical way of distinguishing lambda closures
  from proc and other closures, we need this check in all closures.
* This patch does affect performance of intepreted code in some
  cases.  For example, most of the perf. benefits gained from
  recent patches are lost with this change.
* Worth investigating more closely and maybe selectively enabling
  this only for JIT-ted code, if necessary, for example.
We survived the Mayan Apocalypse!
Eclipse: filter out gems from scanned resources

lib/ruby/gems/* gets bigger and bigger and make Eclipse file scanning
slower.
[IR] Improve upon c73cc11 - add uncaught break handling on demand.

* Commit c73cc11 added global rescue to catch uncaught breaks
  in lambda closures and throw a local-jump-error.  But, this is
  a little excessive and impacts performance some for the
  interpreter.  Updated code to add the global rescue only when
  the interpreter encounters a lambda.  This leaves correctness
  intact and eliminates the try-catch on the vast majority of
  closures in ruby code.

* This opt. is not yet available to the JIT code as of this patch.
  To be explored later.

* Recovers lost performance from commit c73cc11.
Fake cext rb_sourcefile(), rb_sourceline(), ruby_sourcefile.  Fixes #467.
File.truncate should not move write pointer
Merge pull request #473 from atambo/file_truncate

File.truncate should not move write pointer
Fix ffi/ffi#242 by coercing objects passed as :string parameters via #to_str
[IR] Fix IR JIT breakage from b95700d

* Was missing an instanceof check. Fixed now.
Implement fix for ffi/ffi#239 from ruby-ffi
Fix jruby-complete not working with new jossl packaging changes
GH #360: Non-ASCII character escape sequence in string_content results in SyntaxError
Remove libjffi-1.0.jnilib that was checked into git sometime in the past.
Bump version for 1.7.2
update for next dev release
Merge pull request #465 from atambo/const_get

Add const_get to java package Fixes #435
Merge pull request #457 from kou/support-encoding-object-for-encoding-compatible-p

Accept Encoding object for Encoding.compatible?
Reduce cost of repeatedly invalidating global variables.

* Mark all variables as GLOBAL, THREAD, or FRAME scoped
* Only perform indy caching for GLOBAL
* Failover to direct access every time after 100 failures
* Add a failover invalidator that eventually stays invalid

In order to avoid the impact of invalidating global variables that
are modified continually during the run of an application, I've
added a config parameter (invokedynamic.global.maxfail) to fail
those variables and not continue caching them using invokedynamic
and a SwitchPoint. On the update side, I added a new Invalidator
called FailoverSwitchPointInvalidator that eventually gives up and
stays invalid, since even invalidating an unused SwitchPoint is
rather expensive.

With these changes, highly-volatile global variables perform as
well as without invokedynamic, rather than much slower.