using either rackup, puma or torquebox as server and sinatra as
web framework, running from filesystem as is. further using bundler
and having plenty of jar dependencies both locked down (Gemfile.lock
and Jars.lock)

it does delete bin/jruby and lib/jni but will recreate them immediately. this
allows to run ```mvn clean install``` and have everything in place in fresh manner.

Several places used Visibility.values to get a list of all
Visibilities, with the result that they created a new array every
time. There may be other enums with the same usage but they have
not shown up in my profiles.

Fixes #3368

evalType gets tweaked at various stages of block execution, and
when there were two copies in MixedModeIRBlockBody and its
contained CompiledIRBlockBody, they weren't being set consistently
in both places. This change makes them share the threadlocal and
fixes the issues in #3368 leading to eval not scoping right.

The root problem was that evalType is used to indicate that a
given body is being used for an eval, which in this case meant it
was being used for a Class.new class eval. Without the flag, the
search for a method def scope would walk past the Class.new block
and out into the containing class, defining methods in the wrong
place.

TODO: Clean up state like evalType and do a better job of unifying
the different container objects for block bodies.

… ci]

* It could change if mutated while iterating.
* Rubinius #each_item expects this check at least in #select!.

…truffle.

This reverts commit eef0e41.

…hes.

… cases.

This optimization will convert define_method from being a block and fully promoting it to a method (only for JIT now).  Once we unify InterpretedIRMethod and MixedModeIRMethod we can enable this for full builds in -X-C as well.  This ended
up have more issues than anticipated.  block_given? in particular refers to the block outside the define_method block and not to any block passed to that newly defined method.  This required the creation of a new Method type DefineMethodMethod.

The biggest limitation to this optimization is that if the block for define_method references any variables in a parent scope then we will not perform the optimization.  This is mildly undesirable and for read-only lvar access I think we can hoist the value from the parent scope and pass it into our converted method.  This seemed like a ton of extra work so it is a blue sky future.

There will be a future set of commit(s) to make this optimization trigger more often.  Right now if the new method has contained closures which acceess lvars outside of their current scope then we do not perform this opt.  The next round of optimization will involve calculating whether nested closures can escape the define_method only.

Before:

Calculating -------------------------------------
define_method w/ capture
                        56.284k i/100ms
                 def   104.909k i/100ms
       define_method    63.224k i/100ms
-------------------------------------------------
define_method w/ capture
                          1.115M (± 5.8%) i/s -      5.572M
                 def      3.409M (± 9.3%) i/s -     16.890M
       define_method      1.086M (± 4.8%) i/s -      5.437M

After:
system ~/work/jruby master * 1412% jruby ../snippets/define_method3.rb
Calculating -------------------------------------
define_method w/ capture
                        58.167k i/100ms
                 def   108.644k i/100ms
       define_method    92.163k i/100ms
-------------------------------------------------
define_method w/ capture
                          1.171M (± 6.4%) i/s -      5.875M
                 def      3.241M (± 8.1%) i/s -     16.079M
       define_method      2.795M (± 8.7%) i/s -     13.917M

MRI:
system ~/work/jruby master * 1408% mri22 ../snippets/define_method3.rb
Calculating -------------------------------------
define_method w/ capture
                        46.709k i/100ms
                 def    63.690k i/100ms
       define_method    46.901k i/100ms
-------------------------------------------------
define_method w/ capture
                        832.886k (± 6.4%) i/s -      4.157M
                 def      1.732M (± 7.8%) i/s -      8.662M
       define_method    856.637k (± 6.6%) i/s -      4.268M