A suggestion for making ruby more realtime and parallel (and it may not be too hard)

Hello all,
I’ve been working a lot with the ruby gc lately, as part of an exception translating c+±>ruby->c++ communication layer to be used in a hi-spec PC game, and I’ve realised:
*the thing that really stops ruby from working with native threads is
the different stack that each thread gets.
*perhaps it would be possible to split the gc tasks into separate
threads, while keeping all ruby interpretation happening in one
thread.
For example having the mark and sweep phases each running in their own thread, but each thread only having to work with VALUES that have been created from the interpreter thread. The gc threads become consumers of the interpreter producer.

Feedback?
Lorien Dunn