> Parallel tracing needs an assumption that "do not move (free) memory
> area except sweeping timing". Current CRuby does.
> For example: "ary << obj". Yes, the CRuby's memory management strategy
> (assumption) is different from normal interpreters.
If you allocate an object somewhere --after-- that area has been scanned, the GC will treat that area as garbage, and then you will have memory corruption, leading to segfaults and other nice things.
While parallel mark/sweep is certainly doable (Java does this) it's not easy to get right.
Concurrency, as I understand it, is dividing things into tasks that can run (to some degree) independantly of eachother.
Parallelism is two or more concurrent tasks running simultaniously.
This if you have one gc thread and one application thread, you have the possibility of them running in parallel.
But in the context of GC (in my understanding) the distinction goes like
* concurrent GC is when (some phases of) the garbage collection happen in a separate thread from the main program.
* parallel GC is when (some phases of) the collection are performed by multiple threads.
So e.g. in a mark&sweep collector you can have a background thread that performs the mark phase concurrently or you can have a parallel collector that uses multiple threads to perform the mark phase.
In MRI you can't do the latter but it could be possible to do the former, according to the thread referenced earlier.
Here is a good introductory talk: http://www.infoq.com/presentations/Understanding-Java-Garbag...
Naively, with Ruby's mark-sweep collector, you might want to do the sweep phase in parallel, adding garbage blocks to the free list. You could do the mark phase as well, with I believe a pause to make the marks a consistent snapshot.
 http://www.oracle.com/technetwork/java/javase/tech/g1-intro-..., for one.
EDIT: what I mean is that there is still a need for locks, but a lot of work can be done concurrently.