-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Binger wrote:
>> If we are serious about making Durus scale to huge databases then I
>> think there are other issues to fix as well.  For example, even with
>> an on disk index for record offsets, packing still requires memory
>> proportional to the number of objects in the DB.
>
> I'm pretty sure we could modify the packing code to avoid that.

A mark&sweep collector, like the current one in Durus, will need memory
proportional to live objects in the storage. Unless you use disk as
memory (paging) and pay a big speed tax.

My current investigation in GC for my BerkeleyDB backend is a cycle
detector (if no cycles, the reference counters will manage pretty well),
where I only need to consider objects previously linked from modified
objects, no the total storage... unless an object keeps a reference to
the root object :-p. That is my nightmare, by the way :p

Garbage Collection is hard.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea@jabber.org         _/_/    _/_/          _/_/_/_/_/
                               _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRB/jbZlgi5GaxT1NAQIZSAQAmlZaiG82uv8LMhW7mpdvzPAkWXH1S4GZ
Ax7842l6Mc8f3xMhgxnn3ty7k5qnhLFiT1hRJZPZaF8ElhTHqUVilUwk61RvDXpk
0T0Vo5gcDVE71FJLu4vksv+cPDVAP957ot6qzhaNZEhPSjZn6RPdx4+QFWxawgjA
tzlHpExQwmM=
=jNKz
-----END PGP SIGNATURE-----