Introduce explicit scanned state for mature GC

This uses an additional bit for the mark field, which now has a separate
flag to indicate that the object has been completely scanned. This will
be used in the write barrier for concurrent collection. This is needed
for the case where we store an unmarked object into an already scanned
object so we don't accidentally free the unmarked object.

This makes the black state of the tri color GC invariant explicit.
Before this was implicit by it being black when it was marked and not
anymore in the mark stack. For concurrent GC we want this explicit so we
don't have to check the mark stack in each write barrier.
Update write barrier with checking for scanned objects

This verifies that when writing a value through the write barrier, we
check whether the target has been scanned. If it has, we track the
stored value so it can be processed during the finalization phase of
concurrent collection.

The memory barrier ensures other threads that might run the write barrier see the
updated status properly so they run the write barrier correctly.
Introducing concurrent mature mark phase

This creates the option of having a concurrent mark phase for the mature
GC, which is enabled by default.

The strategy is a straightforward implementation, where we first do a
stop the world and an initial scan of the roots and threads. After this
we start a concurrent mark phase.

If the mark stack has been processed concurrently, we stop the world
again and rescan the roots and threads. We also mark all objects that
have been writting into the mark set through the write barrier. After
this we mark all pending objects as a final phase.

Because we don't want to prevent a young GC while we're doing a
concurrent mark phase, we have to do some additional work for young GC
cycles if a mature mark phase is in progress. We basically scan all
mature objects in the mark stack, because they act like a remember set
and can point to young objects.

We also have to remove any unreachable young objects from the mark
stack. The weakref list needs the same treatment here during a young GC.

Another thing we do is rescan all the marked RData objects. This is
needed because there is no write barrier for those in a C extension, so
we have to make sure to rerun rb_mark() to ensure we scan them properly.
Otherwise there might be active references inside an object wrapped with
Data_Wrap_Struct we accidentally clean up.

When an object is promoted during the young GC, we explicitly clear the
current mark. This is done so we will remark it through the write
barrier, and the underlying lines in Immix will be marked for this
object. Otherwise we will think the object is marked, but the underlying
immix lines aren't and will be reused, resulting in crashes.

The marker thread basically functions like any auxiliary thread, like
the signal and finalizer threads. After a fork or before an exec, we
explicitly say the mature mark isn't in progress anymore. Mature marking
can be properly restarted then afterwards because it would never finish
and would never start a new mature cycle anymore otherwise.
Improve young GC auto tuning

This allows for automatically growing the young generation space if
there is a lot of pressure on the young generation. This pressure is
measured to tracking how much young GC's happen while we do a concurrent
GC.

If this more than once, we check the current size of the young
generation and request a growth if the mature space is larger than the
young space by a given factor. The current default factor is 8, which is
a fairly conservative factor based on metrics obtained through
benchmarks.
Add basic benchmarks for GC with different survivor rates

This measures the number of object allocations done in scenario's where
a different fraction of the objects survives. The survival creates
different GC pressure patterns that we can compare.

This is one of the things used for tuning the garbage collector.
Fix deadlock when forking when immix thread is active

The problem was that it would try to go independent while the lock was
still held. This would deadlock with another thread that wanted to wait
until the immix thread was ready for forking.
Explicitly cast mark to int
Merge branch 'master' into concurrent_gc
Don't remove finalized objects from remember set

With concurrent GC this can cause problems. The issue is that the
concurrent mark stack still has a reference to an object that makes this
finalized object reachable. This is because the concurrent GC started
when the object was still reachable and not yet scheduled for
finalization.

The finalization itself is fine here and not problematic, but the
problem occurs when it's removed from the remember set. This finalized
mature object might hold references to young objects. If during the time
of the mature mark phase, we run additional young GC's, these references
become invalid since the finalized object is no longer remembered.

Not removing this from the remember set ensures we keep updating these
young objects so they stay reachable for the concurrent marking phase.
This results in these objects staying alive somewhat longer than
necessary, namely until the next mature GC phase. There is however no
way around this since we need to ensure that during concurrent marking,
no objects go out of scope that are still reachable in some form.
Fix type of lifetime variables
Merge branch 'master' into concurrent_gc

Conflicts:
	vm/oop.hpp
Fix VM test for marking young objects
Merge branch 'master' into concurrent_gc
Merge branch 'master' into concurrent_gc
Merge branch 'master' into concurrent_gc
Merge branch 'master' into concurrent_gc
Merge branch 'master' into concurrent_gc
Merge branch 'master' into concurrent_gc
Merge branch 'master' into concurrent_gc
Merge branch 'master' into concurrent_gc