-----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-----