Updated CI specs to RubySpec d906aaf0.
Ivar reading only reads memory and doesn't modify
Print class name we read ivar from in JIT debugging

Make it easier to see what the class is we guard the ivar read against.
Setup self class for block based on creator info

This allows the JIT to inline ivar reads inside inlined blocks, for
example in cases like this:

def foo
  ary.each {|e| e == @bar }
end
Allow for compiled blocks to also have a receiver class

Before the additional data was either a block environment or a receiver
class, but having a receiver class is also useful for compiling blocks.
This matters for example for inlining instance variable reads if just a
block is compiled.

Improves benchmark/tiers/0/bm_vm1_ivar.rb significantly:

Before:
=== bin/rbx ===
  ivar read 58492061.6 (±3.0%) i/s -  289205872 in   4.948913s
   ivar set 41165744.5 (±2.6%) i/s -  204915000 in   4.982051s

After:
=== bin/rbx ===
  ivar read 266371814.2 (±5.6%) i/s - 1283690000 in   4.836606s
   ivar set 224551559.4 (±4.0%) i/s - 1110346272 in   4.953298s
Remove unused extra_ field
Optimize performance of Kernel#rand
Convert a bunch of tier1 benchmarks to Benchmark.ips
Merge pull request #2216 from ryoqun/oprofile-blog-post-final

Add a blog post for profiling JIT-ted code with OProfile
Sort CompiledCode init code and use LLVM guard
Fix mis-aligned text
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.