Sort CompiledCode init code and use LLVM guard
Fix mis-aligned text
Remove disused tags
Fix Array#delete for 1.9
Merge pull request #2230 from kachick/fix-array-delete

Fix Array#delete for 1.9
Merge pull request #2231 from kachick/update-spec-tags

Remove disused tags in String for 1.9+
Splat in compiledcode is always a fixnum
Fix for retrieving UnboundMethod parameters.

Before this commit the code tasked with retrieving method parameters would
produce incorrect results. For example, take the following method definition:

    def example(number, &block)
      another_number = 20
    end

    method(:example).parameters

This would lead to the following output:

    [[:req, :number], [:block, :block], [:block, :another_number]]

This was caused due to everything that remains (after processing other argument
types) being assigned as block arguments.

This patch fixes this issue by keeping track of the index of the block argument
and comparing this to the list of local variables similar to how splat
arguments are handled.

Signed-off-by: Yorick Peterse <yorickpeterse@gmail.com>
Tests for correctly retrieving block arguments.

Signed-off-by: Yorick Peterse <yorickpeterse@gmail.com>
Cleaned up code for retrieving method parameters.

The use of Array#map would require the use of Array#compact to get rid of
NilClass values in the parameters collection. An easier (and probably a bit
faster way) of doing this is to simply use Array#each and push values into
another Array.

Signed-off-by: Yorick Peterse <yorickpeterse@gmail.com>
Fix thread safety issue for flushing variable scopes

There was a race condition when flushing the variable scope, because
another thread might already see isolated set to true, before the heap
locals were properly initialized.

This result in this other thread seeing nil as the local value instead
of the proper value. This commit changes the flushing strategy to be
both safe for reads and writes of the locals.

The first step is to delay the allocation of the heap locals tuple. We
then atomically indicate that this scope uses heap locals. If any other
thread also wants to use the scope, it will spin until the heap locals
have been allocated. Spinning for both the read and write ensures that
we don't see any intermediate state during the move from stack to heap
locals. This means no writes are lost and no stale reads occur.

We then create the heap locals and only store then in the heap_locals_
ivar after initializing them, so any reads or writes will see the proper
locals and write to the correct slots.

Fixes #2124
Fix indent
Add spec for File.basename and File.extname

Verifies the behavior when filenames have names with multibyte
characters.
Fix File.basename and File.extname

Makes sure we treat the strings here as all binary, since we only have
to search for direct matches and work with those. Prevents having to
convert back and forth to character vs. byte indexes all the time and we
already have the helpers for working with this byte based.

Fixes #2227
Use correct scope by setting CompiledCode::scope

In some cases, wrong ConstantScope can be used when JIT is enabled.

For example, ConstantScope should be different with each invocation of
class_exec in the following code:

    definition_block = proc do
      proc do
        def baz
        end
      end.call
    end
    Foo.class_exec(&definition_block)
    Bar.class_exec(&definition_block)

But, it becomes always same after this code is JIT-ted.

The cause is the following commit's modification for perfmance. It changed to
only initialize CompiledCode::scope if it's nil:

    e3e230646aa1330c19727b3fde6bf38248733a6c Improve block creation speed

    // TODO: We don't need to be doing this everytime.
    -    cm->scope(state, call_frame->static_scope());
    +    if(cm->scope()->nil_p()) {
    +      cm->scope(state, call_frame->static_scope());
    +    }

But this is wrong, as shown above, there are cases where unconditional
overwriting of ConstantScope is needed.

Also, this diverges from the code of the create_block VM instruction defined
at vm/instructions.def. This also indicates something wrong.

So, always initialize CompiledCode::scope here too.
Merge pull request #2234 from ryoqun/jit-scope-bug

Use correct scope by setting CompiledCode::scope
Trigger full GC from CodeManager to fix memory use

There is a possible situation of excessive memory usage.

It's when many CompiledCode objects are repeatedly created and internalized. In
that case, many MachineCode objects are internally created but never collected.
Thus, memory usage increases forever.

The following test code exhibits the problem:

    prc = proc do
    end

    loop do
      prc.block.instance_variable_set(:@compiled_code,
                                      prc.block.compiled_code.dup)
      prc.call
    end

In such a situation, CompiledCode objects are collected immediately as young
objects by GC. It means that the full (mature) GC is never triggered.

When CompiledCode is internalized, it creates a MachineCode object, a kind of
CodeResource, which is managed and garbage-collected by CodeManager.

Currently, CodeManager only collects unneeded code resources in full (mature)
GC. So, if there is no trigger for the full GC, code resources are never
collected. This is usually fine because code resources are created very
spontaneously under normal conditions.

To fix this, when centain number of code resources (currently, 64 MiB in data
size wise) are newly added, trigger the full GC from CodeManager.

Closes #2224.
Merge pull request #2225 from ryoqun/compiled-code-leak

Trigger full GC from CodeManager to fix memory use
Add Rubinius specific spec for string building

This ensures that we cover the behavior of string interpolation where
the string doesn't have an encoding yet. This is possible on Rubinius,
we only setup the encoding then in the method retrieving the encoding
from the string.

This is an extraction from issue #2222 and is added to prevent
regressions in this behavior.
Don't ignore encodings from strings without it set

Those strings should be treated as strings with ASCII-8BIT encoding.
This change doesn't break any existing specs and also a regression spec
was added to make sure this behavior keeps working properly.

Fixes #2222