[ruby-core:27592] Re: better GC?

> Toshio Endo and Kenjiro Taura adapted the Boehm conservative GC
> to *dramatically* reduce pauses with incremental collection. =A0Their GC =
adds
> about 10% to execution times on a single core CPU, but improves
> execution times over basic mark-and-sweep
> on multi-core CPU -- by allowing marking to run
> in parallel on multiple cores.
>
> This GC seems like a good fit to me. =A0Since most folks running Ruby alr=
eady
> use multi-core processors, it should be an all around performance "win".
>
> Has anyone looked into grafting this GC into MRI?

I looked into it once and...didn't get too far [I wasn't quite sure
how to mark the roots, and once I did get something that somewhat
worked, it seemed slower than the default GC].

If I did it again I would probably do something like
disable the GC (GC_disable)
have periodic calls to garbage_collect (like it does now)
within garbage_collect mark the roots and then call collect (GC_gcollect)

that might be a more sane way of trying it out.
That being said, typically GC only uses 10% of a ruby's time (I
think), so it's not a super high performance hit currently.

I've also been working on some "native type" wrappers [1] whose goal
is basically to reduce the amount of memory Ruby has to traverse in
order to do its mark and sweep.

ex:
a =3D GoogleHashSparseIntToInt.new

a[3] =3D 4 # it saves these away as native C ints, so ruby's GC
basically ignores all members.

I'd be happy to add more functionality [like native {saved away}
strings] or a wrapper to sets/priority queues/std::vector if anybody
would find it useful just let me know.

-r
[1] http://github.com/rdp/google_hash