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
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.
Use single-arg version of RubyClass#newInstance(), instead of the IRubyObject[] variant
Use a CallSite per callback parameter - a particular callback param almost always receives an instance of the same class.
Change MemoryIO from an interface to an abstract class, and hoist isDirect and address into the base class, so isDirect() and address() are monomorphic calls.
Check that the RubyString stored MemoryIO is of the same type (direct/heap) as the requested type before using it.
Speedup to_ptr coercions by using a callsite per parameter
Lookup the MemoryIO directly when convering parameters to pointers, and delay the strategy lookup until the non-direct path is taken.
Limit the amount of recursion for :pointer parameters when passed an object that responds to :to_ptr
Coerce objects using #to_str for :string parameters (for ffi/ffi#242)
Coerce to String instead of raising an error when handed a non-String param (related to ffi/ffi#242)
Instead of calling respondsTo() and then callMethod(), just lookup the method and call via the DynamicMethod instance.
Bignum#div raise ZeroDivisionError if the argument is Float zero
Merge pull request #470 from atambo/bignum_div

Bignum#div raise ZeroDivisionError if the argument is Float zero
Switch to a new concurrency-friendly inst var table impl.

(Description by Charles Oliver Nutter)

The new logic ensures that if two instance variable writes
occur and one or both cause the table to grow, no writes
will be lost. This was an issue before this change, and
under some circumstances early in a program's execution
(or early in a type's lifecycle) could cause data to be
lost.

See the concurrency-interest thread starting here:

http://cs.oswego.edu/pipermail/concurrency-interest/2012-December/010499.html

The implementation has three forms, for different JVM
setups:

* A version using OpenJDK 8's "fences" API for explicitly
performing memory fences.

* A version using volatile fields and Unsafe.

* A version using full synchronization.

The first version is preferred, if the JVM supports it. If
running on a non-OpenJDK 8 (b71+) JVM, the volatile +
unsafe + atomics version is used. Otherwise, we fallback
on a plain synchronized form. In most deployments, this
will not happen.

Performance of the new code does not appear to be
significantly better or worse than the old code on the
red/black benchmark we frequently use for testing.

http://i3.minus.com/ibzMT8X2FkyzJn.png

There will almost certainly be additional work in the future
to make instance variables faster, more concurrency-
friendly, and with more explicit volatility options and
guarantees.

Many thanks to @the8472 for doing the research and
development of this new logic. Thanks also to the folks
on the JVM concurrency-interest list for helping us
settle on the right amount of volatility and fencing
needed to meet our guarantees.

Squashed commit of the following:

commit 1679870e21cf574f214d4b8b354836d8e7f0b88d
Author: the8472 <github@infinite-source.de>
Date:   Sun Jan 6 07:50:11 2013 +0100

    due to the switch from atomic field updater (which had implicit fences)
    to normal volatile access we need to upgrade to fullfence.

commit 48c3527bcceae94d11a699c554b98d04eff5a486
Author: the8472 <github@infinite-source.de>
Date:   Sun Jan 6 07:48:54 2013 +0100

    spec did not not run long enough to catch all failures -> bump up
    iterations

commit 61b8ed28de809213b3c4362ef57ac17ccb8eca0f
Author: Charles Oliver Nutter <headius@headius.com>
Date:   Sun Jan 6 00:11:38 2013 -0600

    Provide an Unsafe from Java 8 to build against.

commit 626a2404f77c792d221889439d7ee08151496cec
Author: the8472 <github@infinite-source.de>
Date:   Sun Jan 6 06:43:55 2013 +0100

    better separation of sync/unsafe code paths -> fix NPE

commit 5fdc9635ae9c6b02faff822ac2d94bba44297375
Author: the8472 <github@infinite-source.de>
Date:   Sun Jan 6 05:57:42 2013 +0100

    remove stacktraces.

commit f4801eacea58dd314eb632218862b3e7ab38a976
Author: the8472 <github@infinite-source.de>
Date:   Sun Jan 6 05:46:25 2013 +0100

    java6 has no precalculated offsets in Unsafe -> calculate them ourselves

commit d1b61e267189827143c035ef16cf7635a68e7890
Author: the8472 <github@infinite-source.de>
Date:   Sat Jan 5 22:22:29 2013 +0100

    remove unused imports

commit f9b9153f67adf1f6d9b0b6be24a673018c5713a6
Author: the8472 <github@infinite-source.de>
Date:   Sat Jan 5 21:49:32 2013 +0100

    return to original load order and java 1.6 compliance level since we
    don't need method handles in UnsafeHolder anymore

commit 93c397d426c320d9a57e68f39318f238e8767a68
Author: the8472 <github@infinite-source.de>
Date:   Sat Jan 5 21:48:53 2013 +0100

    add java 1.8-equivalent sun.misc.Unsafe stub to build against (needs to
    be integrated into build process) and remove method handles from
    UnsafeHolder

commit ced082bb47b2bff45dcea9d11b3a7ae73eb9cdc0
Author: the8472 <github@infinite-source.de>
Date:   Fri Jan 4 14:24:31 2013 +0100

    improve spec and bench

commit 68d51b28e28d1af2fbb341421b4baac32d6a87f8
Author: the8472 <github@infinite-source.de>
Date:   Fri Jan 4 14:24:05 2013 +0100

    get rid of AtomicIntegerFieldUpdater, it performs class inheritance
    checks checks. bad for opto.

commit bc865bc5748a3ea798415be0d3f05efe8462e7c1
Author: the8472 <github@infinite-source.de>
Date:   Fri Jan 4 14:22:57 2013 +0100

    call unsafe directly to make the profiler happy (swap for commented-out
    code to use method handles)

commit 554c6ec3f04fee23b806ca4b8497585440942fd3
Author: the8472 <github@infinite-source.de>
Date:   Fri Jan 4 04:47:53 2013 +0100

    improve test to do proper warmup

commit 0b5bee059dda838cf3cab3e3dd52287a06cd6ae4
Author: the8472 <github@infinite-source.de>
Date:   Fri Jan 4 03:56:22 2013 +0100

    benchmark for ivar access

commit 67f4e58fe0d2bd7013b3b35a931291878dd6c683
Author: the8472 <github@infinite-source.de>
Date:   Fri Jan 4 00:28:35 2013 +0100

    failing test for github issue #476

commit 10db883df55918fb0248b10ec7276c11c83e20b9
Author: the8472 <github@infinite-source.de>
Date:   Thu Jan 3 23:30:00 2013 +0100

    move up JDK in build order to take precedence over jsr292-mock for
    building

commit 74ac1d229f6774777c0ff06a1f1b56f79748c065
Author: the8472 <github@infinite-source.de>
Date:   Thu Jan 3 23:28:58 2013 +0100

    update to current maven-eclipse builder and project nature

commit d0e667d6b5abe9f4f132d66641e965cbb2d9265b
Author: the8472 <github@infinite-source.de>
Date:   Thu Jan 3 23:28:09 2013 +0100

    add copyright header template and switch to java 1.7 building for now

commit 9cece1815633ca4f765ed1c9815386a79a380f93
Author: the8472 <github@infinite-source.de>
Date:   Thu Jan 3 23:26:35 2013 +0100

    initial work on stamped lock ivar table

Signed-off-by: Charles Oliver Nutter <headius@headius.com>
Improve compilation of some multiple-assignment targets.

* All targets are non-expression, so remove variability there.
* AttrAsgn targets can propagate non-expression and be faster in
invokedynamic logic (no need to peel Nth argument off for return).

More work can be done to simplify all targets into non-expression
forms, which will then omit the popping of the last value and
possibly cascade non-expression behavior to contained elements.
Compiler must clear $! for early return from method-level rescue.

A method-level rescue was optimized in recent months to not
completely deoptimize and create a separate child method with full
scoping. However, in the process of optimizing that, we returned
to using normal flow control rather than exception-based flow
control. This caused a literal return inside such a rescue to not
clear $! as it should, since it immediately escaped the method
rather than passing through finally logic.

I modified rescue logic to always use exception-based return (and
friends) in order to ensure that the finally logic triggered. This
is not the ideal way to fix the bug, but it's good enough for now.